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1  Introduction 

Concurrent  programming  is  an  intense  area  of  research  in  computer  science.  There  are 

two  types  of  concurrent  programming.  Multiprogramming  refers  ,to  multiple  processes 

executing  on  a  single  processor  in  the  same  time  period  by  using  a  method  called  “Time- 
9 — 

slicing  .  Multiprocessing  refers  to  multiple  processes  which  execute  at  the  same  time  each 
on  its  own  processor.  This  paper  deals  with  the  issues  of  multiprocessing.  A  process  is 
defined  as  a  section  of  code  which  is  executed  sequentially.  " 

Concurrent  programming  has  become  popular  for  two  primary  reasons.  First,  the  computer 
hardware  industry  has  been  building  more  and  more  complex  multiprocessing  systems  at 
cheaper  and  cheaper  costs.  Second,  multiprocessing  systems  enable  programmers  to  build 
software  systems  which  run  at  a  speed  unobtainable  on  most  single  processor  systems. 
New  complex  applications  which  require  such  speed  involve  database  systems,  large-scale 
scientific  applications,  and  real  time,  embedded  systems. 

However,  there  is  a  problem  with  these  new  multiprocessing  systems.  The  problem  centers 
around  the  fact  that  the  software  industry  has  failed  to  keep  pace  with  the  multiprocessing 
enhancements  produced  by  the  hardware  industry.  A  great  amount  of  research  has  been 
accomplished  and  many  models  of  concurrent  processing  have  been  developed  that  deal 
with  the  issues  of  concurrent  programming.  However,  few  working  systems  have  been 
produced  which  allow  the  programmer  to  effectively  use  the  multiprocessing  environment. 
Those  which  have  been  produced  provide  little  or  no  standardization.  The  main  issues  of 
concurrent  programming  are  process  creation,  synchronization,  and  communication. 

This  paper  has  two  objectives.  The  first  objective  is  to  investigate  and  document  the 
mechanisms  for  process  creation  and  control  on  a  commercial  multiprocessing  system.  The 
Texas  A<kM  Sequent  Balance  8000  Multiprocessing  System  is  the  target  of  this  objective. 
The  second  objective  is  to  add  a  new  mechanism  to  this  existing  system  that  easily  and 
clearly  expresses  process  creation.  j  v  ~ 
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Section  2  of  this  paper  discusses  the  hardware  of  the  Sequent  Balance  8000  Multiprocessing 
System.  Section  3  introduces  the  DYNIX  Operating  System  and  discusses  the  mechanisms 
provided  for  process  creation  and  control.  Examples  are  included  for  each  mechanism  in 
order  to  clearly  demonstrate  the  functionality.  Section  4  discusses  the  implementation 
of  a  precompiler  for  the  C  programming  language  which  provides  programmers  with  the 
“cobegin-coend”  construct.  This  construct  allows  programmers  to  easily  create  concur¬ 
rent  processes.  Section  5  discusses  the  problem  of  synchronization  and  provides  software 
solutions  to  the  mutual  exclusion  problem. 
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1  Introduction 


Concurrent  programming  is  an  intense  area  of  research  in  computer  science.  There  are 
two  types  of  concurrent  programming.  Multiprogramming  refers  to  multiple  processes 
executing  on  a  single  processor  in  the  same  time  period  bv  using  a  method  called  “Time¬ 
slicing”.  Multiprocessing  refers  to  multiple  processes  which  execute  at  the  same  time  each 
on  its  own  processor.  This  paper  deals  with  the  issues  of  multiprocessing.  A  process  is 
defined  as  a  section  of  code  which  is  executed  sequentially. 

Concurrent  programming  has  become  popular  for  two  primary  reasons.  First,  the  computer 
hardware  industry  has  been  building  more  and  more  complex  multiprocessing  systems  at 
cheaper  and  cheaper  costs.  Second,  multiprocessing  systems  enable  programmers  to  build 
software  systems  which  run  at  a  speed  unobtainable  on  most  single  processor  systems. 
New  complex  applications  which  require  such  speed  involve  database  systems,  large-scale 
scientific  applications,  and  real  time,  embedded  systems. 

However,  there  is  a  problem  with  these  new  multiprocessing  systems.  The  problem  centers 
around  the  fact  that  the  software  industry  has  failed  to  keep  pace  with  the  multiprocessing 
enhancements  produced  by  the  hardware  industry.  A  great  amount  of  research  has  been 
accomplished  and  many  models  of  concurrent  processing  have  been  developed  that  deal 
with  the  issues  of  concurrent  programming.  However,  few  working  systems  have  been 
produced  which  allow  the  programmer  to  effectively  use  the  multiprocessing  environment. 
Those  which  have  been  produced  provide  little  or  no  standardization.  The  main  issues  of 
concurrent  programming  are  process  creation,  synchronization,  and  communication. 

This  paper  has  two  objectives.  The  first  objective  is  to  investigate  and  document  the 
mechanisms  for  process  creation  and  control  on  a  commercial  multiprocessing  system.  The 
Texas  A&M  Sequent  Balance  8000  Multiprocessing  System  is  the  target  of  this  objective. 
The  second  objective  is  to  add  a  new  mechanism  to  this  existing  system  that  easily  and 
clearly  expresses  process  creation. 
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Section  2  of  this  paper  discusses  the  hardware  of  the  Sequent  Balance  8000  Multiprocessing 
System.  Section  3  introduces  the  DYNIX  Operating  System  and  discusses  the  mechanisms 
provided  for  process  creation  and  control.  Examples  are  included  for  each  mechanism  in 
order  to  clearly  demonstrate  the  functionality.  Section  4  discusses  the  implementation 
of  a  precompiler  for  the  C  programming  language  which  provides  programmers  with  the 
“cobegin-coend”  construct.  This  construct  allows  programmers  to  easily  create  concur¬ 
rent  processes.  Section  5  discusses  the  problem  of  synchronization  and  provides  software 
solutions  to  the  mutual  exclusion  problem. 
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2  Sequent  Balance  8000  Architecture 


The  Sequent  Balance  8000  is  a  tightly  coupled,  symmetric,  multiprocessor  computer  with 
a  common  pool  of  shared  memory.  Sequent  Computer  Systems,  Inc.  released  the 
Balance  8000  in  1984.  The  Balance  8000  supports  both  general  purpose,  multiuser  ap¬ 
plications  and  dedicated  parallel  applications.  The  Balance  8000  is  based  on  a  Shared 
Memory  Architecture.  This  means  that  processes  communicate  by  reading  and  writing 
to  shared  data  structures.  Processes  can  execute  on  any  CPU,  independent  of  any  other 
process.  The  processes  use  shared  memory  to  communicate  and  to  synchronize  activities. 

The  Balance  8000  operating  system,  DYNIX,  is  a  version  of  UNIX  4.2bsd  that  has  been 
enhanced  to  provide  features  of  UNIX  System  V  and  to  exploit  the  features  of  the  parallel 
architecture.  DYNIX  includes  a  Parallel  Programming  Library  that  simplifies  the  use  of 
shared  memory  and  the  system’s  hardware-based  mutual  exclusion  mechanisms.  It  also 
distributes  the  responsibility  of  scheduling,  handling  interrupts,  and  housekeeping  duties 
among  the  CPUs. 

The  Balance  8000  is  an  expandable,  high  performance  parallel  computer.  The  Balance  8000 
has  a  chassis  which  can  contain  12  card  slots  into  which  component  boards  are  placed  and 
configured.  The  following  boards  can  be  used:  MULTIBUS  adapter  board,  CPU,  Memory 
module,  or  a  SCED  board.  The  Balance  8000  includes  three  buses,  one  system  bus  and 
two  I/O  buses. 


2.1  SB8000  Bus 

The  Balance  8000  is  built  around  a  32  bit  wide  bus  called  the  SB8000.  This  bus  links 
the  system’s  CPUs,  system  memory,  and  I/O  subsystems  as  shown  in  Figure  1.  The 
SB8000  supports  data  packets  of  1,  2,  3,  4,  or  8  bytes  and  has  a  channel  bandwidth  of  40- 
Mbytes  per  second  with  a  sustained  data  transfer  rate  of  26.7  Mbytes  per  second.  Optimal 
performance  is  obtained  by  using  data  packets  of  4  or  8  bytes.  This  common  data  bus 
greatly  simplifies  the  addition  of  system  components. 


3 


V  ■  L  «  .  , 


•  ■  .  > 


mT  s'  *  m  *  ■  m 


Figure  1 

BALANCE  8000  OVERVIEW 
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2.2  Processor  Boards 


The  Balance  3000  can  have  from  two  to  twelve  NS32032  CPUs  (packaged  two  to  a  board). 
The  CPUs  run  at  10MHz  and  include  a  floating  point  unit,  a  memory  management  unit,  an 
8  Kbyte  local  memory,  and  an  8  Kbyte  cache.  Each  CPU  shares  memory  via  the  SB8000 
(see  Figure  2).  Each  CPU  is  identical  and  can  execute  both  user  code  and  kernel  code. 
Each  CPU  issues  a  24  bit  virtual  address  (every  process  can  access  up  to  16  Mbytes).  The 
CPU’s  Memory  Management  Unit  translates  that  address  into  a  25  bit  physical  address. 
The  SB8000  supports  a  28  bit  address  and  uses  the  higher  order  bits  to  address  the  different 
TO  subsystems.  The  local  memory  holds  highly  used  kernel  code  and  data  structures  to 
decrease  contention  on  the  SB8000.  The  cache  memory  also  reduces  the  contention  for  the 
SB8000  bus.  Cache  data  is  organized  into  512  rows  each  with  two  eight  byte  blocks.  If 
a  read  miss  occurs  on  a  processor’s  cache,  a  new  block  of  data  is  read  from  memory  and 
replaces  the  least  recently  used  block  of  cache.  If  a  CPU  wishes  to  write  to  memory,  it  will 
first  update  its  cache  if  the  block  resides  in  the  cache.  It  will  then  send  a  write  request 
to  the  SB8000  bus  to  update  the  block  in  memory.  Each  processor  monitors  all  writes  to 
memory.  If  write  to  memory  from  another  processor  addresses  a  block  in  cache,  the  block 
is  marked  as  out-of-date  and  a  read  miss  will  occur  next  time  it  is  accessed.  The  Computer 
Science  Department’s  system  currently  conta' ns  10  CPUs. 


2.3  Memory  Modules 


The  system  can  support  up  to  four  memory  modules  with  a  total  of  28  Mbytes  of  physi¬ 
cal  memory.  An  individual  process  can  access  up  to  16  Mbytes  of  virtual  memory.  Each 
memory  module  consists  of  a  memory  controller  (which  contains  2  Mbytes  of  RAM),  and 
optionally,  a  memory  expansion  board  with  2-6  Mbytes.  A  memory  controller  and  expan¬ 
sion  board  occupy  one  slot  in  the  Balance  8000  chassis.  Each  memory  module  can  respond 
to  a  read  request  in  300  ns  (3  cycles,  2  cycles  Mr  a  4  or  8  byte  read  or  write  request). 
Multiple  operations  are  pipelined  to  enhance  performance.  Memory  modules  can  also  be 
interleaved  if  equal  sized  memory  modules  are  used.  It  would  appear  that  the  Balance 
8000  can  access  up  to  32  Mbytes  of  memory  (25  bit  physical  address  and  four  memory 
modules  with  8  Mbytes  each).  However,  one  Mbyte  of  memory  is  leserved  for  each  of  a 
possible  four  MULTIBUS  adapter  boards, 
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2.4  SCED  Board 


The  Balance  8000  requires  at  least  one  SCED  board  and  can  contain  up  to  four.  The  SCED 
board  supports  many  functions.  It  connects  to  the  Small  Computer  Systems  Interface 
(SCSI)  bus.  This  bus  is  designed  to  support  high  speed,  high  volume  data  transfers 
between  memory  and  peripherals  such  as  disk  and  tape  drives.  The  SCED  board  allows 
the  Balance  8000  to  connect  to  other  systems  in  the  local  area  using  Ethernet.  It  is  used  to 
perform  system  startup  and  system  diagnostics.  The  SCED  board  also  provides  a  RS232-C 
interface  to  connect  the  system  console.  The  SCED  board  packages  data  into  eight  byte 
blocks  to  efficiently  use  the  SB8000  bus. 


2.5  MULTIBUS  Adapter  Board 


The  Balance  8000  can  include  up  to  four  MULTIBUS  adapter  boards.  The  MULTIBUS 
adapter  board  connects  to  MULTIBUS,  a  general  purpose  bus  protocol  that  supports  a 
wdde  variety  of  terminals,  printers,  disk  units,  and  tape  drives.  Peripherals  can  include 
RS232-C  compatible  devices  such  as  a  one-half  inch  tape  drive  or  a  396  Mbyte  disk  drive. 
These  peripherals  can  be  connected  via  one  or  more  terminal  multiplexors  on  the  MULTI¬ 
BUS. 


2.6  SLIC  Bus 


The  SB8000  includes  an  independent  one  bit  data  path  called  the  System  Link  and  In¬ 
terrupt  Controller  (SLIC).  This  bus  is  for  low  level  communication  (interrupts)  between 
system  components.  The  SLIC  bus  supports  a  high  speed,  synchronous,  bit  serial,  proto¬ 
col.  Every  component  board  on  the  Balance  8000  includes  a  Sequent  designed  VLSI  SLIC 
chip.  All  SLIC  chips  are  connected  to  the  SLIC  bus  to  manage  interprocessor  communi¬ 
cation,  access  to  kernel  data  structures,  interrupts,  diagnostics,  and  configuration  control. 
Only  one  operation  can  be  performed  on  the  SLIC  bus  at  a  time.  If  two  CPUs  both  try 
to  use  the  SLIC  bus  at  the  same  time,  the  one  with  the  lowest  priority  will  wait.  If  both 
CPUs  have  the  same  priority,  the  one  with  the  highest  CPU  number  succeeds.  The  CPU 
priority  is  based  on  the  priority  of  the  process  currently  executing  on  the  CPU.  To  ensure 
that  a  CPU  will  eventually  access  the  SLIC  bus,  priorities  are  updated  once  every  second. 
Processes  which  have  been  idle  longest  receive  higher  priorities. 


2.7  Mutual  Exclusion 


s 


In  any  multiprocessor  system  based  on  a  shared  memory  architecture,  mutual  exclusion 
is  an  issue.  Mutual  exclusion  ensures  that  a  sequence  of  operations  acts  as  an  indivisible 
operation.  Any  operation  on  a  shared  variable  should  be  completed  before  another  process 
accesses  that  shared  variable.  The  Balance  8000  solves  the  mutual  exclusion  problem  by 
providing  programmers  with  a  set  of  hardware  locks.  The  Balance  8000  can  have  up  to  64K 
hardware  locks  (16K  locks  for  each  MULTIBUS  configured).  These  locks  are  physically  lo¬ 
cated  on  the  MULTIBUS  Adapter  Boards  and  are  known  as  Atomic  Lock  Memory  (ALM). 
Each  time  a  lock  is  accessed,  a  test-and-set  operation  is  performed.  This  operation  is  an 
atomic  operation  which  will  test  the  slate  of  the  lock  (LOCKED  or  UNLOCKED),  LOCK 
the  lock  if  it  is  UNLOCKED,  and  return  its  state.  The  main  purpose  of  the  hardware  locks 
is  to  ensure  mutual  exclusion  on  a  set  of  virtual  software  locks.  The  software  locks  are 
created  by  the  programmer  and  placed  in  an  application’s  shared  memory.  An  application 
can  create  as  many  software  locks  as  will  fit  in  its  shared  memory.  These  software  locks 
ensure  the  mutual  exclusion  needed  by  an  application  for  its  critical  sections.  The  soft¬ 
ware  locks  work  the  same  as  the  hardware  locks,  except  their  operations  are  not  atomic. 
A  process  must  first  obtain  a  hardware  lock  before  accessing  its  software  locks  to  ensure 
that  the  software  lock’s  operations  are  atomic.  After  a  process  has  obtained  a  hardware 
lock,  it  may  perform  an  operation  on  its  software  lock.  The  process  will  then  release  the 
hardware  lock  for  other  processes  to  access.  To  ensure  that  multiple  processes  attempting 
to  obtain  the  same  software  lock  first  obtain  the  same  hardware  lock,  a  relationship  must 
be  set  up  between  the  two  types  of  locks.  DYNIX  accomplishes  this  through  a  hashing 
algorithm,  where  the  address  of  the  software  lock  is  hashed  to  an  address  of  a  hardware 
lock.  This  implies  that  many  unrelated  applications  may  try  to  obtain  the  same  hardware 
lock.  Although,  this  may  slightly  effect  the  run  time  of  an  application,  mutual  exclusion 
is  still  ensured.  The  routines  found  in  the  DYNIX  Parallel  Programming  Library  enable 
programmers  to  create  and  use  software  locks.  By  using  these  routines  the  operations  on 
the  hardware  locks  become  transparent. 


3  Parallel  Programming  Library 


This  section  introduces  the  routines  which  comprise  the  Parallel  Programming  Library. 
These  routines  support  multitasking  in  C,  Pascal,  and  FORTRAN.  The  library  is  located  in 
/usr/lib/libpps.a.  These  routines  can  be  linked  to  a  program  from  the  library  by  including 
the  -Ipps  option  in  the  cc  command  for  C  programs,  the  -mp  option  when  compiling  Pascal, 
or  the  -F  option  when  compiling  FORTRAN  programs.  The  following  discussion  and 
examples  are  limited  to  the  C  programming  language.  Not  every  routine  in  the  Parallel 
Programming  Library  is  covered,  but  most  of  the  routines  are  discussed  and  examples 
are  included  to  illustrate  their  use.  In  addition  to  the  routines  found  in  the  Parallel 
Programming  Library,  the  fork,  exit,  and  wait  routines  are  explained.  These  three 
routines  are  found  in  any  current  version  of  Unix  and  provide  a  simple  mechanism  to 
create  multiple  concurrent  processes. 

DYNIX  includes  two  C  header  files  which  contain  declarative  statements  for  the  Par¬ 
allel  Programming  Library  routines.  Both  of  these  header  files  reside  in  the  directory 
/usr/ include /parallel.  The  header  files  are  named  microtask. h  and  parallel. h.  Refer  to 
Section  3P  in  the  DYNIX  Programmer’s  Manual  and  Appendix  C  in  this  document  for 
information  on  which  file  to  include  for  each  routine.  These  files  are  included  in  each  of 
the  examples  that  illustrate  routines  from  the  Parallel  Programming  Library. 

DYNIX  uses  two  terms  to  describe  parallel  programming,  microtasking  and  multitasking. 
The  terms  relate  to  two  different  methods  which  are  used  to  partition  a  program  for  parallel 
execution.  Microtasking  refers  to  the  idea  of  “Data  Partitioning”.  In  this  method,  a  set  of 
data  is  partitioned  into  subsets  where  separate  identical  processes  are  created  to  perform 
the  desired  work  on  each  subset  of  data.  The  key  word  is  “identical”.  Each  process  is  an 
exact  duplicate  of  every  other  process.  The  only  difference  is  that  each  process  will  work 
on  different  data.  The  classic  example  is  an  iterative  loop,  where  each  iteration  accesses  a 
different  set  of  data.  Almost  all  of  the  routines  in  the  Parallel  Programming  Library  seem  to 
be  geared  for  this  technique.  Multitasking  refers  to  the  idea  of  “Functional  Partitioning”. 
In  this  method,  functions  are  separated  instead  of  data.  This  usually  requires  a  more 
flexible  and  dynamic  approach.  The  fork  routine  is  used  for  this  type  of  partitioning.  It  is 
a  misconception  to  think  that  the  Parallel  Programming  Library  routines  can  handle  every 
type  of  multiprocessing  application.  The  new  DYNIX  parallel  programming  routines  were 
never  meant  to  replace  the  basic  fork,  but  to  extend  its  capabilities  in  certain  contexts. 


The  use  of  shared  memory  is  also  often  misunderstood.  In  the  C  programming  language, 
a  global  variable  is  not  shared  between  separate  processes  (however,  in  Pascal,  global 
variables  are  shared).  Any  variable  or  structure  which  is  to  be  shared  between  processes 
must  be  declared  as  shared.  The  key  word  shared  must  proceed  the  type  of  a  variable 
within  its  declaration.  You  must  link  a  program  with  the  Parallel  Programming  Library 
to  use  shared  memory,  even  if  you  do  not  use  any  routine  from  the  library.  Remember, 
it  is  your  responsibility  to  provide  for  any  synchronization  needed  between  processes  to 
ensure  correctness. 

3.1  Fork 

The  fork  creates  a  new  process.  The  new  process’s  instructions,  user-data,  and  system- 
data  segments  are  almost  exact  copies  of  those  of  the  old  process.  The  old  process  which 
issued  the  fork  is  called  the  “parent”  and  the  newly  created  process  is  called  the  child. 
The  only  difference  between  the  two  processes  is  that  the  child  has  a  unique  process  id 
(PID)  and  a  different  parent  process  id  (the  PID  of  the  old  process).  The  fork  returns  an 
integer.  After  the  fork,  both  processes  (the  parent  and  the  child)  receive  a  return.  The 
parent  process  will  receive  the  PID  of  the  newly  created  child.  The  child  will  receive  a  0. 

Example  1  shows  a  process  which  issues  a  fork  to  create  a  child.  Both  processes  then 
print  out  what  was  returned  by  the  fork.  The  output  of  the  example  follows  and  shows 
two  numbers  returned  by  the  fork,  12538  and  0.  12538  is  the  PID  of  the  child  and  was 
returned  to  the  parent.  O  was  returned  to  the  child. 

Notice  the  system  call  setbuf.  This  command  sets  the  size  of  the  buffer  which  writes  to 
a  file.  I  used  the  command  to  set  the  buffer  size  of  the  standard  output  file  (terminal)  to 
zero  (NULL).  When  a  parent  creates  a  child,  the  child  gets  a  copy  of  the  parent’s  open  file 
descriptors.  This  means  that  each  can  overwrite  what  the  other  has  written  by  writing  to 
the  same  buffer.  The  buffer  size  is  set  to  zero,  so  that  what  ever  is  written  by  parent  or 
child  immediately  goes  to  the  terminal.  To  fully  ensure  that  no  output  is  lost,  one  must 
perform  I/O  within  mutually  exclusive  areas  called  critical  regions.  Mutual  exclusion  will 
be  demonstrated  later. 


finclude  <stdio.h>  * 

/•  This  program  demonstrates  the  fork  system  call.  Fork  will  create  o  •/ 
/•  new  process  known  as  the  child  process.  The  parent  process  is  the  •/ 
/»  process  which  executed  the  Fork.  The  child  process  is  almost  an  ♦/ 
/•  exact  copy  of  the  parent.  Both  the  child  and  parent  process  will  •/ 
/•  resume  execution  after  the  Fork.  Fork  will  return  the  value  of  0  to  •/ 
/•  the  child  process  and  will  return  the  Process  ID  (pid)  of  the  child  »/ 
/»  to  the  Parent  process.  In  this  example  both  processes  print  out  the  •/ 
/*  value  returned  from  the  Fork.  •/ 


mo  in  (  ) 


i n  t  pid; 

setbuf  (stdout ,  NULL); 
printf  (“Start  of  Test\n" ); 
pid  =  fork  (); 

printf  ("pid  returned  is:  55  d  \  n  ' 


Start  of  Test 

pid  returned  is:  12538 

pid  returned  is:  0 


“*  A  *'*  *> ,  •  t  vV 


3.2  Getpid 

Any  process  may  find  out  its  PID  by  issuing  a  call  to  getpid.  The  following  example 
shows  how  to  issue  the  call  to  getpid  and  print  a  process’s  PID.  In  example  2,  the  parent 
first  calls  getpid  and  prints  out  its  PID.  The  parent  then  issues  a  fork.  Notice  that  the 
fork  is  within  an  if  statement.  If  the  fork  returns  a  zero,  getpid  is  used  to  obtain  and 
print  the  PID.  This  is  the  normal  method  of  designating  the  child  and  the  section  of  code 
the  child  is  to  execute.  The  parent,  who  receives  a  nonzero  response,  skips  that  section  of 
code  and  terminates. 


ft 


(((include  <stdio.h> 


/•  Example  2 

/ . 


This  program  will  use  the  system  call  "getpid"  to  find  out  the  •/ 
process's  ID.  After  printing  the  PID,  the  process  will  Fork  o  •/ 
new  process.  The  new  child  process  will  also  cell  "getpid"  ond  •/ 
print  the  result.  Each  process  created  under  UNIX  has  a  unique  •/ 
PID.  •/ 


i  n  t  p  i  d  ; 


pid  =  getpid  (); 

printf  ("Porent  Process  is  /5d\n", 
if  (fork  ()  ==  0 )  } 

pid  =  getpid  (); 

printf  ("Child  Process  is  %d\n‘ 

i 


Eft 


Parent  Process  is  10844 
Child  Process  is  10845 


A  V-lT././ 


SvSv 


3.3  Exit  and  Wait 


The  exit  routine  terminates  a  process.  A  process  which  performs  an  exit  may  pass  (as 
a  parameter)  a  short  integer  value  back  to  the  parent  which  acts  as  a  termination  code. 
The  value  zero  is  usually  returned  to  the  parent  to  indicate  a  normal  termination.  If  the 
process  finds  an  error,  it  may  wish  to  exit  with  a  termination  code  (such  as  -1)  which 
indicates  to  the  parent  process  that  an  error  occurred.  One  may  fork  a  child  process  to 
execute  some  segment  of  code  embedded  within  the  program.  To  accomplish  this  task, 
fork  the  child  and  test  for  a  return  of  zero  as  done  previously.  The  child  should  execute 
the  section  of  code  within  the  if  statement.  Place  an  exit  statement  at  the  end  of  the  if 
statement  to  terminate  the  child  process.  Otherwise,  the  child  process  will  continue  past 
the  if  statement  and  execute  code  which  the  parent  is  executing. 

The  wait  routine  is  used  by  a  parent  process  to  wait  until  a  child  process  has  terminated. 
The  wait  returns  the  PID  of  the  child  which  terminated.  It  also  returns  the  termination 
code  of  the  child  process  (normally  passed  back  by  the  child  using  exit).  This  code  is 
placed  in  an  integer  variable  which  is  passed  to  the  wait  routine  in  a  parameter.  If  a 
process  issues  a  call  to  wait  and  has  no  children  processes  executing,  wait  immediately 
returns  a  -1  as  the  PID.  A  parent  process  can  not  wait  for  a  specific  child  to  terminate.  If 
any  child  terminates,  the  wait  is  satisfied.  If  the  parent  knows  the  PID  of  the  child,  it  can 
test,  the  PID  returned  by  wait  to  find  out  which  child  terminated.  The  parent  may  have  to 
wait  through  several  terminations  to  find  a  specific  termination.  There  is  no  requirement 
that  a  parent  must  wait  for  a  child  process,  but  the  parent  may  choose  to  wait  if  it  is 
dependent  on  some  action  taken  by  the  child  process.  In  this  capacity,  the  wait  acts  as  a 
synchronization  mechanism. 


Example  3  uses  both  exit  and  wait,  status  is  used  to  hold  the  returned  termination  code 
of  a  terminating  process.  This  aspect  of  wait  and  the  Union  statement  is  discussed  in  the 
next  example.  This  program  also  demonstrates  the  capability  to  nest  fork  calls.  In  this 
program,  the  parent  process  gets  and  prints  its  PID  (by  use  of  getpid).  It  then  forks  a 
child  process,  prints  the  message  “Parent  Running”,  and  issues  a  wait  for  the  child.  The 
child  process  also  gets  and  prints  its  PID;  forks  a  child  process  (the  grandchild);  prints 
the  message  “Child  Running”;  and  waits  for  the  grandchild.  The  graiiucliiid  process  gets 
and  prints  its  PID,  prints  the  message  that  it  is  terminating,  and  then  terminates.  After 
the  grandchild  terminates,  the  child  prints  the  PID  of  the  grandchild  that  terminated.  It 


then  prints  a  message  that  it  is  terminating  and  does  so.  The  parent  process  then  prints 
the  PID  of  the  child  that  terminated  and  terminates. 


This  program  has  two  interesting  points.  The  first  is  the  order  of  the  output.  Notice 
that  the  parent  is  still  executing  as  the  child  executes  and  the  child  is  still  executing 
as  the  grandchild  executes  (concurrency).  However,  the  child  blocks  execution  until  the 
grandchild  has  terminated  and  the  parent  blocks  un'  l  the  child  has  terminated.  The 
second  point  is  that  the  termination  of  a  process  is  only  seen  by  its  immediate  parent.  In 
other  words,  the  parent  process  did  not  notice  the  creation,  execution,  or  termination  of 
the  grandchild  process. 


j 


E  x  omp I e 


(^include  <  s  t  d i o . h> 

^include  <sys/wait.h> 

/•  This  progrom  creates  three  processes.  The  main  process  will  print 
/•  its  PID  and  Fork  a  new  process.  The  child  process  prints  its  P1D 

/»  and  Forks  a  new  process.  The  Grandchild  process  prints  its  PID 

/•  and  Exits.  Both  the  parent  and  child  process  print  a  message  to 

/•  show  that  they  are  executing  concurrently  with  their  children. 

/•  The  Parent  then  performs  o  Wait  on  the  Child  and  the  Child 

/•  performs  o  Wait  on  the  Grandchild.  When  a  process  terminates  with 

/«  an  Exit  system  coll,  the  termination  status  is  returned  to  the 

/•  parent  process.  The  Wait  system  call  also  returns  the  PID  of  the 

/•  terminating  child  process.  In  this  example  the  Parent  prints  the 

/«  PID  of  the  terminating  child  process. 


union  wait  status; 
i  n  t  p  i  d  ; 

setbuf  (stdout,  NULL); 
pid  =  getpid  (); 

printf  ("Parent  Process  is  /5d\n",  pid); 
if  (fork  ()  ==  0)  J  /•  For 

pid  =  getpid  (); 

printf  ("Child  Process  55d\n",  pid); 
if  (fork  ()  ==  0 )  |  / *  For 

pid  =  getpid  (); 

printf  (  "G randch i  I d  Process  is  Xd\n”,  prd); 

printf  ("Grandchild  E  x  i  t  s  \  n  "  )  ; 

exit  (0);  /•  Gron 


/•  Fork  the  Child  *  / 


/*  Fork  the  Grandchild  */ 


/*  Grandchild  Terminates  »/ 


printf  ("Child  Runn i ng\n" ) ; 

p  i  d  =  wa i t  (4s  tatus)  ;  /• 

printf  ("Grandchild  %d  Finished\n",  pid); 
printf  ("Child  E  x i t  s\n " ) ; 

exit  (0);  / . 


/»  Wart  for  the  Grandchild  »/ 


printf  ("Parent  Running\n"); 
pid  =  wait  (Jcstatus); 

printf  ("Child  %d  Finished  \n",  pid) 
printf  ("Parent  Exits\n“); 


/*  Child  Terminates  •/ 


/•  Wait  for  the  child  •/ 


Parent  Process  is  10857 
Parent  Running 
Child  Process  10858 
Child  Running 

Grandchild  Process  is  10859 
G  r  andc  h i  I d  Exits 
Grandchild  10859  Finished 
Child  Exits 
Child  1 0858  Finished 
Porent  Exits 


3.3.1  Detecting  Errors  using  Exit  and  Wait 

How  does  one  use  the  wait  routine  to  catch  a  bad  termination  code?  Stud}’  example 
4.  In  this  example  a  process  forks  a  child  process  and  immediately  waits  for  that  child 
to  terminate.  The  child  process  gets  and  prints  its  PID  and  then  terminates  with  an 
abnormal  termination  code  of  3  (remember  that  0  is  a  normal  termination).  After  the 
child  terminates,  the  parent  tests  the  status  for  normal  termination.  The  variable  status 
is  used  to  hold  the  termination  code  returned  by  wait. 

There  are  two  ways  for  a  process  to  terminate.  It  can  call  exit  or  it  can  receive  a  fatal  signal 
from  the  system.  Although  status  is  just  an  integer,  its  bits  indicate  how  it  terminated. 
If  the  rightmost  byte  of  status  is  zero,  then  the  byte  to  its  left  is  the  child’s  argument  to 
exit.  If  both  are  zero,  the  child  terminated  normally.  If  the  rightmost  byte  is  nonzero, 
the  first  seven  bits  are  the  signal  number  that  terminated  the  child.  If  the  eighth  bit  is  1, 
a  core  dump  was  taken.  The  bits  of  status  are  counted  right  to  left  (15,  14,  ...  2,  1,  0). 

In  this  example,  status  is  declared  as  type  union  wait.  This  union  has  a  structure  of 
the  three  bit  fields  just  described.  This  allows  one  to  check  and  print  the  different  codes 
without  performing  shift  operations.  In  order  to  use  this  union  declaration,  include  the 
header  file  sys/wait.h.  This  header  file  defines  the  union  of  status.  In  the  example,  the 
parent  checks  status. w status.  This  is  declared  in  union  wait  as  the  entire  integer.  If  it  is 
zero,  the  child  terminated  normally.  If  it  is  not  zero,  the  parent  prints  a  message  that  the 
child  terminated  abnormally  and  then  checks  status. wAermsig.  If  this  is  zero,  the  child 
placed  the  termination  code  in  exit  and  the  parent  prints  this  code.  If  it  is  nonzero,  the 
child  terminated  from  a  fatal  signal  and  the  parent  prints  the  signal  number.  The  parent 
will  also  check  for  a  core  dump.  Notice  in  the  output  that  the  termination  code  of  3  was 
printed.  The  man  command  can  be  used  to  reference  the  DYNIX  Programmers  Reference 
Manual.  The  command  “man  2  wait”  can  be  used  to  gather  more  information  on  the  wait 
routine. 


/•  Example  4  *  / 

/ . / 


# i nc I ude  <s  t  d  i  o . h> 

^include  <sys/wait.h> 

/•  This  program  i  I  I  u  s  t  r  a  t 
/•  by  the  Wait  system  cal 
/•  header  file  <sys/wait. 
/•  unsigned  short  integer 
/•  operating  system  termi 
/  *  terminating  code.  Bit 
/•  the  rightmost  byte  is 
/•  abnormally,  then  bits 
/»  by  the  process  through 
/•  the  child  process  retu 
/»  to  set  up  his  own  term 
/•  are  counted  right  to  I 


es  the  use  of  the  Status  value  returned 
I.  Once  again,  you  must  include  the 
h>.  The  Status  returned  is  actually  an 
The  rightmost  8  bits  are  set  if  the 
noted  the  process.  Bits  0  -  6  give  the 
7  is  set  if  a  core  dump  was  taken.  If 
0  and  the  process  still  terminated 
8-15  contain  the  stotus  code  returned 
the  Exit  system  call.  In  this  example 
rns  a  value  of  3.  This  allows  a  user 
inotion  codes.  The  Bits  of  the  Status 
eft  (15,  14  ...  3.  2,  1,  0). 


ma  in  ( ) 


union  wait  status;  /•  bit  field  set  up  by  <sys/woit.h>  •/ 
i  n  t  p  i  d  ; 

setbuf  (stdout,  NULL); 
pid  =  getpid  (); 

printf  ("Parent  Process  is  Zd\n" ,  pid); 

if(fork()==0)  J  />  Fork  the  Child  •/ 

pid  =  getpid  (); 

printf  ("Child  Process  /5d\n",  pid); 

exit  (3);  />  Child  Terminates  Abnor«ially  •/ 

i 

pid=wait  (tstotus);  /‘Wait  for  the  child  •/ 


if  (status -w.status  !=  0)  ) 


/•  Abnormal  Termination?  •/ 


printf  ("\n\nProcess  %d  hod  Abnormal  Tern  i  not  i  on\n’1  ,  pid). 

if  (!  status . *_te  rms i g)  /•  Terminated  by  System’  •/ 

printf  ("Exit  Code:  J5u\n",  stotus.  w_rel  code)  ; 
else  } 

printf  ("Terminated  by  System  Error:  %u\n",  stotus ,w_te  rms i g) 

if  ( 'lotus . w.coredunp)  /*  Core  Dump  Token?  •/ 

printf  ("Core  Dump  Taken\n"); 


Porent  Process  is  10874 
Child  Process  10875 


Process  10875  hod  Abnormol  Termination 
Exit  Code  3 


3.3.2  Detecting  Errors  on  Forks 


When  a  process  forks  another  process,  it  would  be  nice  to  know  whether  the  fork  was 
successful.  Also,  how  many  processes  can  one  user  have  executing  at  one  time  and  how 
does  one  detect  an  error?  Example  5  shows  how  many  forks  can  be  performed  successfully 
and  how  to  catch  an  unsuccessful  fork.  In  this  program,  the  parent  process  will  print  its 
PID  and  then  start  forking  new  children.  Each  child  goes  into  an  infinite  loop.  This  is 
done  to  ensure  that  no  child  terminates  while  the  parent  is  still  creating  new  children.  The 
parent  keeps  count  of  the  number  of  children  created  and  prints  each  child’s  PID.  When 
a  fork  does  not  succeed,  it  returns  a  -1  instead  of  a  new  PID.  When  the  parent  receives  a 
-1  from  a  fork,  it  breaks  out  of  the  loop.  The  next  problem  is  to  determine  why  the  fork 
was  unsuccessful. 

Notice  the  two  external  variables  sys.nerr  and  sys-errlist.  sys^errlist  is  an  array  of  error 
messages  kept  by  the  system,  sys-nerr  is  the  highest  index  into  the  array  sys.errlist.  The 
external  variable  errno  is  declared  in  the  header  file  errno.h  and  will  hold  the  error  message 
number  of  the  unsuccessful  fork.  In  this  example,  when  the  parent  process  finds  a  bad 
fork,  it  prints  the  number  of  children  created.  It  then  checks  errno  for  an  error  code.  If  an 
error  code  is  found  and  it  is  less  than  sys-nerr,  errno  is  used  as  an  index  into  sys.errlist  to 
print  the  error  message.  The  output  of  this  example  shows  that  a  user  is  able  to  create  25 
processes  (including  the  parent).  The  command  kill  at  the  bottom  of  the  program  allows 
the  parent  to  terminate  all  related  processes.  The  kill  will  also  terminate  the  parent 
process.  The  command  “man  3  sys_nerr”  can  be  used  to  read  about  system  error  messages 
and  the  command  “man  2  intro”  can  be  used  to  list  every  possible  error  message. 


^include  <  s  t  d  i  o  h  > 
find  ude  <errno.h> 


/»  E  x  om  p  I  e  5  «/ 

/ . . . / 


/•  This  program  demonstrates  the  use  of  the  external  variables  •/ 
/•  errno,  sys_nerr,sys_errlist  to  capture  on  unsuccessful  Fork.  •/ 
/•  In  this  program,  as  many  processes  ore  creoted  os  the  system  •/ 
/•  will  allow  one  user  to  c r e "  * e  .  When  the  system  does  not  •/ 
/•  allow  any  more  Forks  by  o  user,  it  returns  a  -1  in  place  of  •/ 
/•  the  PID  and  puts  the  error  code  into  the  global  variable  •/ 
/•  errno.  errno  can  be  used  as  an  index  into  the  array  •/ 
/•  sys_errlist  This  array  holds  error  messages  for  each  error  •/ 
/»  produced  by  the  system.  This  program  counts  the  number  of  •/ 


/• 

processes 

creoted  and  then  prints  the 

error 

message  returned 

•/ 

/* 

from  the 

bad  Fork  Each  Child  process 

goes 

into 

an  in 

f  i  n 

i  t  e 

•/ 

/• 

loop  to  e 

nsure  that  no-one  terminates 

while 

I  am 

t  e  s  t  i 

ng 

f  o  r 

*/ 

/• 

the  e  r  r  o  r 

condition  The  system  coll 

to  Ki. 

II  is 

used 

t  0 

•/ 

/• 

termi note 

all  children  processes.  The 

0  says  to 

s  i  g  n  a 

1  a 

1  1 

•/ 

/• 

processes 

in  my  user’s  goup  (including 

myse 

If). 

the  9 

i  s 

the 

•/ 

/• 

terminate 

s  i  gna  1  . 

•/ 

mo  in  (  ) 

i 

extern  int  sys_nerr; 
extern  char  *sys.err  I  i  st [  ]  ; 
int  count,  ppid,  pid; 

setbuf  (stdout ,  NULL) ; 

count  =  0  ; 

ppid  =  getpid  (). 


printf  ("Parent  Process  is  %d\n", 

ppid); 

printf  ("\n\nCount 

Process\n" ) 

for  ( ; ; )  ) 

pid  =  fork  ( ) ; 

if  (pid  ==  0 ) 

/• 

child  s  p i 

ns  •/ 

for  (  ;  ;  )  )  j 

if  (  p  i  d  >  0 )  J 

/* 

i nc  r  em  e  n  t 

count  and 

•/ 

count  ++  ; 

/* 

print  PID 

of  child 

•/ 

printf  ( "  %d 

i 

7.d\n"  , 

count,  pid) 

: 

I 

else  if  (p'd  <  0) 

/‘ 

Error  on 

Fo  r  k  * / 

break  . 


printf  ("\nTotol  Processes  Created:  5»d\  n "  .  count); 
printf  ("\nError  on  Fork\n"); 
if  ((errno  >  0)  kk  (errno  <  sys.nerr)  ) 
printf  ("5Ss  \n",  sys_er  r  I  i  st  [  er  r  no]  )  ; 
kill  (0,9);  /•  killthechildren 


Parent  Process  is  10887 


Count 

1 

2 

3 

4 

5 

6 

7 

8 
9 

1  0 
1  1 
1  2 
1  3 
1  4 
1  5 
1  6 
1  7 
1  8 
1  S 
20 
21 
22 

23 

24 


Process 
1  0888 
1  0889 
1  0890 
1  089  1 
1  0892 
1  0893 
1  0894 
1  0895 
10896 
1  0897 
10898 
1  0899 
1  0900 
10901 
1  0902 
10903 
1  0904 
10905 
1  0906 
10907 
1  0908 
1  0909 

10910 

10911 


Total  Processes  Created 


Error  on  Fork 
No  more  processes 
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3.4  M_Fork  and  M_Kill_Procs 

The  m_fork  routine  creates  a  number  of  child  processes  and  assigns  the  same  subprogram 
to  each  of  them.  The  number  of  children  created  will  be  the  number  of  processors  available 
divided  by  two.  Each  of  the  child  processes  will  execute  the  subprogram  passed  to  m.fork 
as  a  parameter.  After  a  child  has  executed  the  subprogram,  it  spins  waiting  for  the  parent 
to  assign  it  another  subprogram  via  a  new  m_fork.  The  m_kill_procs  routine  terminates 
all  child  processes  which  were  previously  created  by  an  m_fork. 

In  example  6,  the  main  procedure  creates  five  child  processes  (the  system  had  10  avail¬ 
able  processors).  Each  child  executes  the  function  “savhi”.  After  each  child  process  has 
executed  the  function,  the  parent  terminates  them  with  a  call  to  mJcilLprocs.  In  the 
function  “savhi”,  each  child  process  prints  the  message  “Hello  from  process  PID”.  Notice 
that  the  example  includes  the  two  header  files  parallel /microtask.h  and  parallel/ parallel. h. 

Remember  that  each  child  process  has  a  copy  of  its  parent’s  open  file  descriptors  and  can 
thus  overwrite  another’s  output.  To  ensure  that  no  output  is  lost,  a  critical  region  is  used. 
Only  one  process  can  enter  the  critical  region  at  a  time.  This  is  accomplished  by  using 
the  m_lock  and  fflush  routines.  The  m_lock  routine  sets  up  a  hardware  lock  which  only 
one  process  at  a  time  can  access.  Once  a  process  obtains  the  lock,  it  can  enter  its  critical 
region.  If  it  does  not  obtain  the  lock,  it  spins  and  continues  to  try  to  access  the  lock. 
A  process  which  has  access  to  the  lock  releases  it  by  calling  the  routine  m_unlock.  The 
routine  fflush  is  used  to  flush  the  output  buffer  so  that  no  process  will  overwrite  any 
previous  output.  mJock  is  used  at  this  time  only  to  print  output.  It  is  discussed  in  more 
detail  later. 
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Example 


#  include  <stdio.h> 

§  include  <poral  I e l/mi crotask . h> 

# i nc I ud  e  <porallel/porallel.h> 

/»  This  program  creats  a  number  of  child  processes,  each  executing 
/*  the  procedure  "Sayhi".  The  procedure  "sayhi"  prints  out  the 
/•  message  "Hel lo  from  Process  PID. 

/ •  M_  fork  will  create  N  processes  where  N  is  (the  number  of 
/•  available  processors)  /  2.  The  m_kill_procs  system  coll  will 
/*  terminate  any  processes  created  by  m_fork. 

/*  The  use  of  m_ I ock  and  m_unlock  are  used  here  to  ensure  mutual 
/•  exclusion  when  each  process  is  printing.  Each  process  shares  the 
/«  same  file  pointer  to  stdout,  so  one  process  may  overwrite  another 
/•  process's  output.  The  ffiush  routine  is  used  to  empty  the  buffer 
/*  to  stdout  before  another  process  can  overwrite  the  buffer. 

sayhi  ( ) 


m_ lock  ( ) ; 

pid  =  getpid  (); 

printf  ("Hello  from  Process  55d\n' 
ffiush  (stdout); 
m_unlock  (); 


main  (  ) 


m_fork  (sayhi); 
m_kill_procs  (); 

printf  ("Program  Over\n' 


Hello  from  Process  10944 
Hello  from  Process  10948 
Hello  from  Process  10947 
Hello  from  Process  10945 
Hello  from  Process  10946 
Program  Over 


I 


3.4.1  Fork  versus  M_Fork 


It  is  a  misconception  to  think  that  the  call  to  m_kill_procs  sets  up  a  barrier  that  the 
parent  will  not  pass  until  each  child  has  terminated.  Example  7  is  exactly  as  the  previous 
one  except  for  a  print  statement  between  the  calls  to  mJFork  and  m_kill_procs.  Actually, 
the  m-fork  itself  sets  up  a  barrier.  After  an  m_fork  has  been  issued,  the  parent  will  not 
continue  until  each  child  has  executed  the  designated  function.  In  the  output,  we  see  that 
the  message  “Program  Over”  is  not  printed  until  after  each  child  has  printed  the  message 
“Hello  from  process  PID”.  This  is  a  major  difference  between  fork  and  m_fork.  The 
fork  routine  allows  the  parent  to  continue  executing  while  the  children  execute.  In  fact, 
with  m_fork  the  parent  does  execute  while  the  children  are  executing,  but  as  one  of  the 
children!  In  the  previous  examples,  five  new  processes  were  not  created.  Four  processes 
were  created  and  the  fifth  execution  of  “sayhi”  was  performed  by  the  parent.  This  will 
become  important  when  the  m_single  and  m_multi  routines  are  discussed.  To  show  that 
the  parent  process  actually  performs  as  a  child  when  using  m_fork,  notice  that  the  parent’s 
PID,  10977,  is  also  the  PID  of  one  of  the  child  processes. 


/ . / 

/•  Example  7  •/ 

/ . / 


§ i nc I ude  <  s  t  d i o . h> 

# i nc I ude  <paro I  I e l/m ic  rotosk . h> 

^include  <parallel/parallel.h> 

/•  This  program  creates  a  number  of  processes  which  print  out  the  *  / 
/•  message  "Hello".  m_lock  and  m_unlock  are  used  to  ensure  mutual  */ 


/  *  exclusion  while  each  process  is  printing.  In  this  program,  *  / 
/•  notice  that  a  call  to  printf  is  made  before  the  created  child  »/ 
/  *  processes  are  terminated  by  m_kill_procs.  This  shows  a  basic  *  / 
/*  difference  between  fork  and  m_fork.  When  an  m_fork  is  made,  */ 
/•  the  parent  process  becomes  one  of  the  chi  Id  processes  and  •/ 
/«  prints  one  of  the  "Hello’s".  The  parent  process  does  not  »/ 
/*  continue  executing  after  the  m_fork  coll  until  all  the  created  •/ 
/•  child  processes  have  completed  execution  of  the  m_ forked  */ 
/•  procedure.  Also  notice  that  one  of  the  children  processes  has  »/ 
/*  the  same  PID  as  the  parent  process.  »/ 


say h i  ( ) 

I 

i  n  t  p  i  d  ;  r 

m_ lock  ( )  ; 

pid  =  getpid  (); 

printf  ("Hello  from  Process  55d\n‘‘,  pid); 
fflush  (stdout) ; 
m_un lock  ( )  ; 

I 

main  (  ) 

J 

i n  t  pid; 

pid  =  getpid  (); 

printf  ("Parent’s  PID  is  %d\n",  pid); 

fflush  (stdout); 

m_  fork  (sayhi); 

printf  ("Program  Ove  r\n") ; 

m_  kil!_procs  (); 

\ 


Parent 

* 

s  PID  is  10977 

Hello 

f 

r  om 

Process 

1  0977 

Hello 

f 

rom 

Process 

10981 

Hello 

f  rom 

Process 

1  0978 

Hello 

f 

r  om 

Process 

1  0979 

Hello 

f 

rom 

Process 

10980 

Program 

Over 

3.5  M_Set_Procs  and  CPUS_Online 


P 


When  a  m_fork  is  executed,  the  number  of  processes  which  execute  the  designated  subpro¬ 
gram  is  the  number  of  available  processors  divided  by  two.  In  fact,  this  is  only  the  default 
value  and  the  programmer  has  more  control  than  just  using  this  default.  The  cpus.online 
routine  returns  the  number  of  available  processors  on  the  system.  The  m_set_procs  rou¬ 
tine  declares  the  number  of  processes  to  execute  a  designated  subprogram  in  parallel  on 
subsequent  calls  to  m_fork.  The  total  number  of  processes  which  can  be  running  in  parallel 
using  the  m_fork  routine  is  the  number  of  processors  online  minus  one.  If  a  programmer 
tries  a  higher  number,  the  default  is  used. 

In  example  8,  the  main  process  finds  out  the  number  of  processors  online  using  cpus_online 
and  prints  the  value.  It  then  uses  m_set_procs  to  set  the  number  of  processes  which  can 
execute  in  parallel  to  this  value  minus  one.  Again,  the  function  “sayhi”  is  executed  by 
calling  m-fork.  The  output  shows  that  ten  processors  were  online  at  the  time  and  that 
“sayhi”  was  executed  nine  times. 
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/»  Exorople  8  •/ 

/ . ••••/ 

^include  <stdio.h> 

^include  <poro I  I e l/m i c  rot osk . h> 

^include  <porol  I e I /pa  ra I  lei  .h> 

/•  This  program  is  identical  to  the  previous  progroms  except 
/*  it  sets  the  number  of  processes  to  create.  The  cpus_online 
/•  system  coll  returns  the  number  of  available  CPUs.  The 
/•  m_set_procs  system  coll  will  set  the  number  of  processes  to 
/•  create  on  each  m_fork.  In  this  example,  one  less  than  the 
/•  number  of  CPUs  available  are  created. 


say  h i  (  ) 


i  n  t  p  i  d  ; 

m_ lock  (  )  ; 

pid  =  getpid  (  )  ; 

printf  ("Hello  from  Process  %d\n", 
fflush  (stdout); 
m_  u  n  I  oc  k  (  )  ; 


main  (  ) 

I 

i  n  t  n  um_c  pus; 


num_cpus  =  cpus.onl ine  (); 

printf  ("Number  of  Available  CPUs  is  %d\n' 
fflush  (stdout); 
m_set_procs  (num_cpus  -  1); 


n  um_c  pus) 


m_  fork  (sayhi); 

m_  k ill_procs  (); 

printf  ("Program  Over\n") ; 


Numbe  r 
Hello  f 
Hello  f 
Hello  f 
Hello  f 
Hello  f 
Hello  f 
Hello  f 
He  I  I o  f 
Hello  f 
Program 


of  Available  CPUs  is  10 


rom  Process 
rom  Process 
rom  Process 
rom  Process 
rom  Process 
rom  Process 
rom  Process 
rom  Process 
rom  Process 
Over 


11001 
1  1007 
1  1  002 

11004 

11005 
1  1  008 
1  1  003 
1  1  006 
1  1009 


•• 
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3.6  M_Get_Myid 


Processes  created  by  a  call  to  m_fork  also  have  a  version  of  getpid.  The  m_get_myid 
routine  returns  the  PID  of  the  calling  process.  The  PIDs  are  not  the  same  PIDs  that  are 
found  using  the  getpid  routine.  When  N  processes  are  created  using  m_fork  to  execute 
a  subprogram,  the  PIDs  range  from  0,1,2  ...  N-l.  The  parent  process  (which  also  executes 
the  subprogram)  has  the  PID  of  0.  The  fact  that  these  PIDs  are  not  always  unique  between 
different  users  implies  that  they  are  not  the  real  PIDs  seen  by  the  system  kernel,  but  PIDs 
used  by  some  executive  module  which  oversees  the  execution  of  m_fork  and  the  other 
microtasking  routines.  The  PIDs  become  quite  useful  when  partitioning  a  program  by  the 
iterations  of  a  loop. 

Example  9  shows  a  process  which  executes  the  function  “getpid”  three  times.  Each  process 
will  get  their  PID  using  the  m_get_myid  routine  and  print  its  value.  Each  process  also 
gets  their  PID  using  getpid.  Notice  the  output  shows  the  PIDs  from  m_get_myid  to  run 
from  0  to  2.  Notice  that  the  PIDs  from  getpid  are  different  from  those  using  m_get_myid. 
Also,  the  PID  of  the  parent  process  matches  the  getpid  PID  (12617)  of  the  process  with 
the  m_get_myid  PID  of  0. 


/»  Examp  I e  9  */ 

/* . / 


^include  <  a  t  d i o . h> 
jj(  i  n c  I  u d e  < pa  r  a  I  I  e  I  /m  i  c  r  o  t  a  s  k  .  h> 

§  i nc  I  ude  <pa r a  I  I e I /pa r a  I  I e I  . h> 
ijfdef  i  ne  NPROCS  3 

/•  This  program  creates  three  child  processes.  Eoch  process  will  •  / 

/*  get  its  process  id  by  using  the  system  coll  m_get_myid.  Eoch  */ 

/•  process  prints  out  its  PID.  The  m_lock  and  m_unlock  is  used  to  •/ 

/•  ensure  mutual  exclusion  for  printing.  The  number  of  processes  » / 

/•  created  by  the  system  call  m_set_procs.  When  a  m_fork  is  •/ 

/»  executed,  NPROCS  copies  of  the  procedure  “get  id"  ore  executed.  »/ 

/»  Actually,  only  NPROCS  -  1  new  processes  are  creoted.  The  */ 

/•  parent  process  will  act  as  one  of  the  new  processes  and  execute  */ 

/*  one  copy  of  "getid“.  The  parent  process  will  have  the  PID  of  0  */ 

/•  and  the  other  processes  will  have  PiDs  of  1,2,3,  ...  NPROCS-1.  •/ 

/•  Each  child  process  will  also  get  its  PID  using  the  getpid  «/ 

/»  routine.  Notice  that  the  two  are  different.  *  / 

g  e  t  i  d  (  ) 

\  r 

int  pidl,  pid2; 

pidl  =  m_get_myid  (); 
pid2  =  getpid  (); 
m_ I oc  k  ( )  ; 

printf  ("My  process  ID  using 
printf  ("My  process  ID  using 
fflush  (stdout); 
m_unlock  (); 

} 

main  (  ) 

) 

int  p i d  ; 

pid  =  getpid  (), 
printf  ("Parent  process  is  %d\n\n",  pid); 
fflush  (stdout); 

m_set_procs  (NPROCS);  /*  Set  the  number  of  processes  to  NPROCS  •/ 
m_  fork  (getid); 

m_kill_procs  ();  /•  Terminate  all  processes  except  the  parent  •/ 

I 


Parent  process  is  12617 
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ng 

m_get__myid 
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ID 

u  s 

ng 

getpid  is: 

12619 

/•  Get  my  process  ID  •/ 


m_get_myid  is:  %d\n",  pidl); 
getpid  is:  %d\n",  pid2); 
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3.7  M_Lock  and  M_Unlock 

The  routines  m_lock  and  m_unlock  have  already  been  shown  to  ensure  mutual  exclusion. 
The  mutual  exclusion  is  not  just  for  printing  output,  but  for  any  section  of  code  which 
could  produce  incorrect  results  if  executed  concurrently.  The  m_lock  routine  creates  and 
initializes  a  hardware  lock.  This  same  lock  is  used  in  every  copy  of  the  subprogram  being 
executed.  When  a  process  calls  m_lock,  a  type  of  test-and-set  operation  is  performed  on 
the  lock.  If  no-one  is  using  the  lock,  the  calling  process  obtains  the  lock  and  may  proceed. 
If  the  lock  is  in  use,  the  calling  process  spins,  trying  to  obtain  the  lock.  A  process  releases 
the  lock  by  calling  m_unlock. 

Example  10  illustrates  the  use  of  m_lock  and  m_unlock.  This  program  increments  a 
counter  which  is  shared  between  three  processes.  Remember  the  counter  must  be  declared 
as  shared  for  it  to  be  placed  in  shared  memory  and  accessible  by  each  process.  The  main 
process  creates  three  copies  of  the  subprogram  “counts”  to  be  executed  in  parallel.  Each 
process  will  attempt  to  increment  the  counter  three  times.  The  processes  use  m_lock  to 
ensure  that  only  one  process  can  increment  the  counter  at  a  time.  A  process  will  print 
its  PID  and  the  value  of  the  counter  after  increasing  the  counter.  The  output  shows  the 
counter  was  incremented  nine  times.  Notice  the  increments  of  the  counter  were  printed  in 
order.  This  demonstrates  the  mutual  exclusion.  However,  notice  that  the  order  a  specific 
process  obtained  the  lock,  incremented  and  printed  the  counter,  and  released  the  lock  was 
arbitrary. 


Example  10 


§ i nc I ude  <stdio.h> 

finclude  <po  r  a  I  I  e  I  /m  i  c  r  o  t  a  s  k  .  h> 

§  include  <poral  lel/paral  lei  .h> 

^define  NPROCS  3 

shared  int  count; 

/•  This  program  illustrates  the  use  of  m_lock.  The  program  counts 
/•  by  increasing  the  value  of  a  variable  in  parallel.  The  program 
/•  maintains  mutual  exclusion  with  a  call  to  m_lock.  Each  copy  of 
/•  the  procedure  increments  the  shared  variable  "count" 

/•  concurrently,  and  therefore,  mutual  exclusion  is  required. 

counts  ( ) 

1 

int  me ,  i  ; 

me  =  m_get_myid  ();  /*  Get  my  PID  »/ 


for  (i =0 ;  i  <  NPROCS;  i++)  i 
m_ lock  ( ) ; 
count  +=  1  ; 

printf  ("process  %d  says  count  is  %d\n",  me,  count); 
fflush  (stdout); 
m_un I oc  k  ( ) ; 


main  (  ) 

! 

count  =  0 ; 


m_set_procs  (NPROCS); 
m_fork  (counts); 
m_kill_procs  (); 

printf  ("counter  over\n"); 


/•  Create  NPROCS  processes  •/ 

/•  Terminate  all  Processes  except  Parent 


process 

process 

process 

process 

process 

process 

process 

process 

process 

counter 


count 
count 
count 
count 
court  t 
count 
count 
count 
count 


3.7.1  The  Fairness  of  Locks 


A  locking  mechanism  is  called  “Fair”  if  a  process  eventually  enters  its  critical  region  af¬ 
ter  trying  to  obtain  the  lock.  The  best  example  might  be  a  queuing  semaphore,  which 
maintains  the  order  of  processes  trying  to  obtain  the  lock  in  a  FIFO  fashion.  However, 
mJock  does  not  block  and  queue  a  process.  On  the  Sequent,  a  process  simply  spins  in 
its  processor  and  repetitively  attempts  to  obtain  the  lock.  This  means  that  if  process  1, 
2,  and  3  each  try  to  obtain  a  busy  lock,  there  is  no  way  of  knowing  which  process  will  be 
the  first  to  enter  its  critical  region. 

Example  11  performs  the  same  counting  function  as  the  previous  example,  however,  a 
timing  routine  has  been  added  to  test  when  a  process  attempts  to  obtain  a  lock  and  - 
when  it  actually  obtains  the  lock.  The  header  file  sys/time.h  must  be  included  to  use  this 
routine.  The  structures  timeval  and  timezone  are  used  with  the  gettimeofday  routine  to 
get  the  desired  information.  The  gettimeofday  routine  returns  a  timing  counter  which  is 
incremented  every  10  milliseconds.  In  the  function  “counts”,  each  process  will  get  its  PID 
and  enter  a  loop  to  increment  count.  In  the  loop,  each  process  will  call  gettimeofday 
before  attempting  the  call  to  m_lock.  After  a  process  has  enter  its  critical  region,  it  again 
calls  the  gettimeofday  routine  for  the  time.  The  process  then  enters  a  second  loop  which 
performs  no  service  except  to  waste  time.  This  is  done  to  ensure  that  more  than  one 
process  is  waiting  to  enter  the  critical  region.  The  counter  is  then  incremented  and  both 
the  counter  and  times  are  printed.  The  process  then  releases  the  lock  for  another  process 
to  enter  its  critical  region. 

The  output  shows  the  counter  is  incremented  in  correct  order.  It  also  shows  the  time 
that  each  process  attempted  to  enter  its  critical  region  and  the  time  it  entered  the  critical 
region.  Notice  that  process  0  on  count  8,  attempted  to  enter  the  critical  region  before 
process  1  at  count  7,  yet  process  1  entered  the  region  first.  Both  had  issued  a  call  to 
m_lock.  It  is  just  by  chance  that  process  1  obtained  the  lock  first.  The  reason  for  this  is 
both  timing  and  hardware.  It  may  be  that  process  1  noticed  the  lock  was  released  before 
process  0.  However,  if  two  processes  attempt  to  obtain  the  same  lock  simultaneously,  the 
process  with  the  lowest  priority  will  wait.  If  both  processes  have  the  same  priority,  the 
process  with  the  lowest  processor  number  will  wait.  Starvation  results  when  one  process 
never  obtains  the  lock.  On  the  Balance  8000,  starvation  will  not  occur  because  the  priority 
of  a  waiting  process  is  increased  over  time.  This  is  called  “Weak  Fairness”.  The  command 
“man  2  gettimeofday”  can  be  used  to  read  about  this  function  further. 


E  x  om  p I e  11 


jjlinclude  <sys/time.h> 

^include  <  s  t  d  i  o  .  h  > 
finclude  <pora I  I  e  l/m i c  rotosk . h> 
finclude  < p a r o  I  I  e I / p a r a  I  I e I  . h> 
fdef i ne  NPROCS  3 

shared  int  count; 


This  program  illustrates  the  use  of  m_lock.  The  program  counts 
by  increasing  the  value  of  a  variable  in  parallel.  The  progrom 
maintains  mutual  exclusion  with  a  call  to  m_lock.  The  system’s 
calls  to  gettimeofday  are  to  show  when  the  process  attempted 
to  access  the  lock  and  when  the  process  obtained  the  lock. 
Although  not  conclusive,  it  would  appear  that  the  m_lock  coll  i: 
not  fair. 


counts  ( ) 

I 

struct  timeval  t,  r;  /•  Timing  Variables  •/ 

struct  timezone  t 1 ,  rl. 

int  me,  i,  j.  k; 
k  =  0  ; 

me  =  m_get_myid  ();  /•  Get  my  PID  •/ 

for  ( i =0 ;  i  <  NPROCS;  i++)  J  /»  Increment  Count  NPROCS  times  •/ 

gettimeofday  (tt,  k t 1 ) ;  /•  Time  before  Access  •/ 

m_ lock  ( ) ; 

gettimeofday  ( &  r  ,  Jr  r  1  )  ;  /•  Time  after  Access  »/ 


gettimeofday  (tt,  k t 1 )  ; 
m_ lock  ( ) ; 

gettimeofday  (k  r  ,  Jr  r  1  )  ; 


for  (j  =  0;  j  <  10000;  j++)  /•  Waste  some  time  •/ 

k  =  j  +  k  ; 

count  +=  1 ; 

printf  ("process  %d  count  is  Zd  me,  count); 

printf  ("  Tried  %d  Zd  Obtained  Zd  Zd\r\",  t.tv_sec, 
t.tv_usec,  r.tv_sec,  r . tv.usec) ; 
fflush  (stdout); 
m_  unlock  ( )  ; 


ma  in  (  ) 

I 

count  =  0 ; 

m_set_procs  (NPROCc',  /• 

m  _  f  o  r  k  (counts); 
m_  kill_procs();  /* 

printf  ("counter  over\n") ; 


Create  NPROCS  processes  */ 

Terminate  all  processes  except  Parent  •/ 
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r.  k,s 


3.7.2  Multiple  Locks 

How  many  times  can  m_lock  be  called  within  a  process?  It  was  thought  that  it  should 
only  be  called  once  for  one  critical  region.  However,  this  is  entirely  up  to  the  programmer. 
mJock  sets  up  one  lock  to  be  used  by  the  programmer.  The  programmer  is  free  to  use 
the  lock  as  he  wishes.  The  following  program  executes  a  new  “counts’’  function.  The  new 
function  increments  two  counters.  Each  process  will  call  m_lock,  increment  and  print  a 
counter  value,  and  call  m_unlock  to  release  the  lock.  The  process  then  attempts  the  same 
procedure  for  the  other  lock.  Each  process  increments  each  lock  three  times. 

The  output  shows  that  each  lock  was  incremented  to  the  value  of  nine  and  that  the  in¬ 
crements  were  all  in  order  from  1  to  9.  However,  notice  that  near  the  end  of  the  output, 
process  0  increments  count2  before  process  1  has  incremented  countl.  In  other  words,  you 
can  not  predict  which  counter  will  be  incremented  next.  This  is  because  the  same  lock  is 
used  for  both  critical  regions.  This  is  a  rather  inefficient  method  since  the  counters  are 
independent  of  each  other. 


V.  /.v.v. 


kV.v 


v.v.vv.v.v 


/•  Example  12 

/ . 

finclude  <s  t  d i o . h> 
find  ude  <pora I  lel/microtast  .  h> 
finclude  <paral lel/paral lei ,h> 

#de  f  i ne  NPROCS  3 

shared  int  count  t  ,  count2; 

/•  This  program  illustrates  the  use  of  m  _  I  o  c  k  .  In  this  program 
/•  m_lock  is  used  twice.  M_lock  uses  just  one  lock.  However, 
/»  You  can  have  multiple  occurrences  of  m_lock  in  a  routine. 

/•  In  this  program  two  shored  counters  are  incrementea  by  all 

/»  copies  of  "counts",  however,  only  one  lock  is  used  for  both 

/•  count  variables. 

counts  () 

I 

int  me ,  i ; 

me  =  m_get_myid  (); 

for  ( i=0,  i  <  NPROCS;  i++)  j 
m_ lock  (  )  ; 
c  o  u  n  t  1  +=  1  ; 

printf  ("process  %d  soys  countl  is  %d\n",  me,  count  t  )  ; 
fflush  (stdout); 
m_ unlock  (); 

m_ I o  c  k  (  )  ; 
c  ou  n  t  2  +=  1  ; 

printf  ("process  %d  says  count2  is  5£d\n",  me,  count2); 
fflush  (stdout); 
m_u  n I oc  k  ( )  ; 

i 

I 

main  (  ) 

! 

countl  =  0 ; 
c  o  u  n  t  2  =  0  ; 

m_set_procs  (NPROCS); 
m_  fork  (counts); 
m_kill_procs  (); 

printf  ("counter  o  v  e  r  \  n  "  )  ; 

I 
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3.7.3  Omission  and  Commission  Errors 


The  last  example  showed  how  a  programmer  can  use  the  calls  to  m_lock  and  m.unlock 
for  his  own  purposes.  This  can  become  a  very  dangerous  situation.  What  would  happen 
if  a  process  tried  to  nest  calls  to  m_lock.  In  other  words,  tried  to  obtain  a  lock  it  already 
had.  Would  the  system  allow  the  process  to  continue?  No!  The  system  does  not  care 
which  process  has  obtained  a  lock  and  who  will  get  it  next.  It  only  ensures  that  only  one 
process  at  a  time  can  use  the  lock.  The  following  example  is  the  original  “counts”  program 
minus  a  call  to  m_unlock  after  leaving  the  critical  region.  This  is  an  inherent  problem 
with  locks  and  semaphores.  The  program  deadlocks  right  away.  After  the  first  process 
obtains  the  lock,  no  other  process  can  continue.  The  process  which  first  obtained  the  lock 
also  waits  when  it  calls  m_lock  on  the  second  iteration.  The  output  shows  that  process 
0  obtained  the  lock,  incremented  and  printed  the  counter.  However,  now  every  process  is 
waiting  for  the  lock  because  process  0  forgot  to  release  it.  Hit  CTRL-C  to  kill  a  program 
which  has  deadlocked. 


/•  Example  13  •/ 

/ . * . / 


>  # i nc I ude  <st  d i o . h> 

§  include  <para!  I e  l/u  i  c rotask . h> 

^include  <parcl  lel/parol  I e I  .  h> 

#de  f  i ne  NPROCS  3 

shared  int  count; 

/•  This  program  attempts  to  increment  a  counter  within  a  critica 
/•  region.  However,  the  program  forgets  to  unlock  the  critical 
/  *  region  and  deadlocks  the  program. 

counts  () 

\ 

int  me,  i ; 

me  =  m_get_myid  (); 

for  ( i =0 ;  i  <  NPROCS;  i++)  j 
m_ lock  (  )  ; 
count  +=  1  ; 

printf  ("process  %d  says  count  is  %d\rT',  me,  count); 
fflush  (stdout); 

} 
i 

main  (  ) 

1 

count  =  0  ; 

m_set_procs  (NPROCS); 
m_fork  (counts); 
m_kill_procs  (); 

printf  ("counter  over\n“); 


i 


process  0  says  count  is  1 


3.8  M_Sync 


) 


The  m_sync  routine  causes  a  process  to  spin  until  all  processes  which  were  m_forked 
have  reached  the  same  point  and  have  called  m_sync.  The  routine  is  used  to  synchronize 
all  processes  which  were  created  by  a  call  to  m_fork.  The  best  way  to  explain  m_sync  is 
by  example.  Example  14  again  increments  a  shared  counter.  Each  process  which  executes 
“counts”,  will  increment  the  counter  N  times,  where  N  is  the  number  of  processes  created 
multiplied  by  the  process’s  PID  +  1  (PID  obtained  by  m_get_myid).  Each  process  will 
execute  an  outer  loop  three  times  (three  processes  are  created).  Each  process  will  then 
enter  another  loop  and  will  increment  and  print  the  shared  counter.  This  next  loop  is 
executed  PID  +  1  times.  This  varies  with  each  process  and  better  demonstrates  m_sync. 

The  output  shows  the  three  iterations  imposed  by  the  outer  loop.  Within  each  iteration, 
the  count  is  incremented  six  times  (once  by  process  0,  twice  by  process  1,  and  thrice  by 
process  2).  Notice  that  all  of  iteration  0  is  performed  before  iteration  1  begins,  even  though 
process  0  is  finished  and  ready  to  continue.  Process  0  waits  for  the  other  two  processes  to 
finish  and  synchronize  before  continuing  to  the  next  iteration. 


/ . •••/ 

/•  Example  14  •/ 

/ . / 


# i nc I ude  <stdio.h> 

^include  <poro I  I e l/mi c  rotosk . h> 
finclude  <porallel/poraltel.h> 

| d e  f i ne  NPROCS  3 

shared  i  n  t  court  t  ; 

/•  This  program  creates  NPROCS  processes  to  execute  the  procedure  •/ 

/•  "counts".  Each  process  will  increment  a  shored  counter  N  times  •/ 

/*  where  N  is  NPROCS  •  (PIO  +  1).  m_sync  is  used  to  synchronize  •/ 

/*  all  processes  before  each  outer  loop  iteration.  •/ 

count  s  ( ) 

\ 

i n  t  me ,  i  ,  j  ,  iterations; 

me  =  m_get_myid  (); 
iterations  =  me  +  1; 

for  (  i =  0 ;  i  <  NPROCS  ;  i  +  +)  j 

for  (j=0;  j  <  iterations;  j++)  j 
m_ I oc  k  (  )  ; 
count  +=  1 ; 

printf  ("iteration  Zd  process  Zd  says  count  is  %d\n",  i,  me,  count); 
fflush  (stdout); 

it  unlock  ();  r 

\ 

m  sync  ();  /•  Synchronize  all  processes  •/ 

I 

} 

mo  in  (  ) 

1 

count  =  0  ; 


m_set_procs  (NPROCS); 
m_  fork  (counts); 
m_  k ill_procs  (); 
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3.9  M_Park_Procs  and  M_Rele_Procs 

A  process  created  by  m_fork  will  spin  waiting  for  more  work  after  it  has  executed  the 
subprogram  named  by  the  m_fork.  If  no  more  work  is  to  be  done,  then  the  process  can 
be  terminated  bjr  a  call  to  m_kill_procs.  What  if  there  is  more  work  for  each  process 
to  do,  but  the  parent  process  must  do  some  initial  work  sequentially?  You  could  leave 
the  processes  spinning  while  the  parent  executes.  This  is  very  wasteful  of  processor  time. 
You  could  terminate  the  processes  and  then  recreate  them  when  needed.  This  solution  is 
wasteful  of  processing  time  due  to  the  amount  of  overhead  needed  to  recreate  the  processes. 
Each  m_fork  requires  a  certain  amount  of  time  to  copy  the  named  subprogram  to  different 
processors  for  execution. 

The  m_park_procs  routine  suspends  execution  of  each  process  which  was  previously  cre¬ 
ated  by  a  call  to  m_fork.  These  processes  still  exist  at  the  different  processors,  but  they 
are  no  longer  spinning.  They  have  been  blocked  and  are  not  active.  The  m_rele_procs 
routine  resumes  the  execution  of  processes  which  have  been  blocked  by  a  previous  call 
to  m_park_procs.  These  two  routines  are  very  useful  and  allow  a  programmer  to  reuse 
processes  without  wasting  processor  time  or  processing  time. 

Example  15  executes  the  original  “counts”  procedure.  The  main  process  creates  three 
processes  to  execute  “counts”  in  parallel.  After  the  processes  are  finished,  the  parent 
process  calls  m_park_procs  to  block  the  processes  from  execution.  The  parent  prints  the 
message  “Take  a  Rest”.  It  then  unblocks  the  processes  with  a  call  to  m_rele_procs  and 
calls  m_fork  to  create  three  processes  to  again  execute  “counts”.  m_fork  is  smart  and 
will  not  create  new  processes  if  they  already  exist.  The  output  shows  that  the  counter  was 
incremented  nine  times.  The  processes  took  a  rest  and  then  the  counter  was  incremented 
nine  times  again.  Notice  that  the  counter  was  incremented  to  the  value  of  nine  on  the  first 
m_fork  and  then  was  incremented  to  the  value  of  18  on  the  second  m_fork.  This  shows 
that  the  counter  does  not  lose  its  value  between  m_forks  and  suggests  that  the  processes 
only  receive  a  pointer  to  shared  variables.  If  the  processes  were  terminated  between  the 
two  calls  to  m_fork,  the  results  would  be  the  same.  If  you  need  a  shared  variable  to  be 
reset  between  calls  to  m_fork,  you  must  do  it  yourself. 


Example  15 


| i nc I ude  <stdio.h> 

#  i  nc I ude  <paro I  I e l/mi c  rotosk . h> 

(((include  <p  a  r  a  I  I  e  I /pa  r  a  I  I  e  I  .  h> 

#def i ne  NPROCS  3 

shared  int  count; 

/•  This  program  illustrates  the  use  of  the  m_pork_procs  call 
/•  Three  processes  are  created  which  count  by  incrementing  a 
/•  shared  counter.  After  NPROCS  iterations  of  counting,  the 
/•  parent  process  parks  each  process  and  prints  a  message. 

/•  After  the  message  is  printed  the  parent  releases  the 
/•  processes  and  continues  counting. 

count  s  ( ) 

I 

int  me,  i  ; 

me  =  m_get_myid  ();  /*  Who  am  I  •/ 


for  ( i =0 ;  i  <  NPROCS ;  i  ++)  j 
m_ lock  (  )  ; 
count  +=  1  ; 

printf  ("process  %d  says  count  is  5Sd\n",  me,  count); 
fflush  (stdout); 
m_un lock  ( ) ; 


ma  in  (  ) 

\ 

count  =  0 ; 


m_set_procs  (NPROCS); 
m_fork  (counts); 

m_park_procs();  /* 

printf  ("\n\n  Take  a  Rest  \n\n"); 
fflush  (stdout); 


m_  re  I e.procs  () 
m_fork  (counts) 
m_kill_procs  () 


printf  ("counter  over\n") 
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process  0  says  count 
process  2  says  count 
process  1  says  count 
process  0  says  count 
process  2  soys  count 
process  1  says  count 
counter  over 


is  10 
is  11 
is  12 
is  13 
is  14 
is  15 
is  16 
is  17 


3.9.1  The  Inflexible  M_Park_Procs 


There  is  one  major  problem  with  m_park_procs.  If  you  want  to  execute  "counts”  three 
times  and  then  execute  it  later  only  two  times,  you  must  terminate  the  original  pro¬ 
cesses  and  create  two  new  ones.  This  problem  goes  back  to  the  call  to  m_set_procs. 
m_set_procs  not  only  tells  how  many  processes  can  execute  in  parallel,  but  also  tells 
m_fork  how  many  processes  to  create.  DYNIX  will  not  allow  you  to  reset  the  number  of 
processes  you  need  for  the  next  m_fork  without  first  calling  mJcilLprocs  to  terminate 
the  current  processes. 

Example  16a  illustrates  this  point.  The  main  process  creates  three  children  to  execute 
“counts”.  After  they  are  finished,  the  main  process  terminates  them  with  a  call  to 
m_kill_procs.  The  main  process  resets  the  counter,  prints  a  message,  and  then  resets 
the  number  of  processes  needed  to  two  by  calling  m_set_procs.  These  two  processes  are 
then  created  bv  a  call  to  m^fork  and  execute  “counts”.  The  output  verifies  the  program. 
If  the  number  of  processes  had  not  been  reset  to  two  using  m_set_procs,  the  m_fork 
would  have  created  three  (due  to  the  previous  value  of  m_set_procs).  If  the  original 
processes  had  not  been  terminated  by  a  call  to  m_kill_procs  before  resetting  the  number 
needed  to  two,  DYNIX  would  have  ignored  the  call  to  m_set_procs.  This  is  illustrated  by 
example  16b.  In  this  example,  the  original  processes  were  not  terminated  before  resetting 
m_set_procs.  Notice  that  three  processes  were  used  to  execute  “count”  after  the  message 
“Take  a  Rest”. 
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/•  Example  16a  */ 

/ . / 


# i nc I ude  <s  t  d i o  h> 

finclude  < pa r a  I  I e I /m i c r o t a s k  .  h > 

^include  <para  I  I  e  l/poro  I  I e  I  . h> 

#def i ne  TWO  2 
#de  f  i  ne  NPPOPP  1 

shared  int  count; 

/»  This  program  illustrates  the  use  of  the  m_ pa r k_ p r o c s  call 
/•  Three  processes  are  created  which  count  by  incrementing  o 
/•  shared  counter.  After  NPROCS  iterations  of  counting,  the 
/•  parent  process  kills  each  process  and  prints  a  message. 

/•  After,  the  message  is  printed  the  parent  creates  two  new 

/•  processes  and  continues  counting. 

counts  (  ) 

\ 

int  me,  i  ; 

me=m_get_myid();  /•  WhoamI  •/ 

for  ( i =0 ;  i  <  NPROCS ;  i ++ )  j 
m_ lock  ( ) ; 
count  +=  1  ; 

printf  ("process  Z.d  says  count  is  Zd\n".  me,  count); 
fflush  (stdout); 
m_un lock  ( ) ; 


main  (  ) 

) 

o  u  n  1  =  0 

m_sef_pro<s  (NPROCS); 
m  f  irk  (counts)  ; 

m_ki:procs(),  /•  Kill  all  children  •/ 

print*  ("\n\n  Take  a  Rest  \n\n"), 


ff I  ash  (stdout). 

Count  ■  0 . 

m.set_procs  t,  TWO  )  ; 
m_fork  (counts) 
m_k  i  1  l..procs  ( )  . 

printf  (" counter  over\n“); 

I 


process 

0 

says 

count 

i  s 

i 

process 

2 

says 

count 

i  s 

2 

process 

1 

soys 

count 

i  s 

3 

process 

0 

says 

count 

i  s 

4 

p  r  oc  e  s  s 

2 

soys 

count 

i  s 

5 

process 

1 

says 

count 

i  s 

6 

process 

0 

says 

count 

i  s 

7 

process 

2 

says 

count 

i  s 

8 

process 

1 

soys 

count 

i  s 

9 

Take  a 

Rest 

process 

0 

says 

count 

i  s 

i 

process 

1 

says 

count 

i  s 

2 

process 

0 

soys 

count 

i  s 

3 

process 

1 

says 

count 

i  s 

4 

process 

0 

says 

count 

i  s 

5 

process 

counter 

1  soys 
over 

count 

i  s 

6 

/•  reset  counter  •/ 

/•  Creote  two  processes 
/•  Put  children  to  work  •/ 


/•  E  xamp I e  16b  »/ 

/•••*•••••••*•••••/ 

|  i  nc  I  ude  <s  t  d i o . h> 

find  ude  <pora I  I e l/m i c  rot  ask . h> 

find  ude  <paral  I  el/parol  I e I  . h> 

#def i ne  TWO  2 
fde f i ne  NPROCS  3 

shared  ini  count, 

/•  This  program  illustrates  the  use  of  the  m_pork_procs  call. 
/•  Three  Drocesses  ore  created  which  count  by  incramenting  a 
/•  shared  counter.  After  NPROCS  iterations  of  counting,  the 

/•  parent  process  prints  a  message. 

/*  After,  the  message  is  printed  the  parent  resets  the  number 
/•  processes  to  two.  Notice  that  three  processes  are  created 
/»  The  system  ignored  the  m_set_procs  routine  because  the 

/•  parent  process  did  not  kill  all  the  children  processes 

/ •  first. 


counts  (  ) 

i 

i n  t  me ,  i  ; 

me  =  m_get_myid  () 


Who  am  I 


for  (  i =0 ;  i  <  NPROCS;  i -M  )  ) 

m_ I oc  k  ( )  ; 
count  +=  1 ; 

printf  ("process  %d  says  count  is  %d\n' 
fflush  (stdout); 
m_u  n lock  ( )  ; 

\ 


me,  count); 


ma  in  (  ) 

count  =  0  ; 

m_set_procs  (NPROCS); 
m_  fork  (counts); 

printf  ("\n\n  Take  a  Rest  \n\n"); 
fflush  (stdout); 
count  =  0 ; 


reset  counter 


m_set_procs  (TWO); 
m_fork  (counts); 
m_  kill_procs  (); 

printf  ("counter  over\n‘ 


/♦  Create  two  processes  »/ 
/»  Put  children  to  work  •/ 


process 

process 

process 

process 

process 

process 

process 

process 

process 


0  says 
2  sa  y  s 
0  says 

1  says 

2  says 
0  says 

1  says 

2  says 


count  is  1 
count  is  2 
count  is  3 
count  is  4 
count  is  5 
count  is  6 
count  is  7 
count  is  8 


1  says  count  is 


Take  a  Rest 

process  2  soys  count 
process  1  soys  count 
process  0  says  count 
process  2  soys  count 
process  1  soys  count 
process  0  says  count 
process  2  says  count 
process  1  soys  count 
process  0  says  count 
counter  over 


■■ 
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3.9.2  The  Efficiency  of  M_Park_Procs  and  M_Rele.Procs 


When  m.fork  is  called,  what  is  copied  to  the  new  processors?  Does  m.fork  only  copy 
the  subprogram  named  in  the  parameter?  Or  does  m.fork  give  each  new  processor  an 
entire  copy  (data  segment,  instruction  segment,  and  system  data  segment)  of  the  process 
which  cedis  it  (like  fork)?  This  is  an  important  question.  If  you  execute  the  function 
“counts”  three  times  and  then  wish  to  execute  the  function  “sayhi”  three  times,  should 
you  terminate  the  original  processes  before  m_forking  “sayhi”  or  should  you  just  block 
them  and  release  them  when  needed?  If  you  do  not  terminate  them,  will  the  m.fork 
expect  the  function  “sayhi”  to  be  on  each  of  the  processors  or  will  it  have  to  copy  the 
function  to  them?  If  the  m.fork  must  copy  the  function  “sayhi”  to  the  processors,  do  you 
save  any  time  by  using  m.park.procs  instead  of  m.kill.procs? 

The  answer  is  that  m.fork  copies  the  entire  environment  of  the  calling  process  to  the  new 
processors.  Therefore,  on  subsequent  calls  to  m.fork,  no  new  data  or  instructions  need 
to  be  copied.  This  means  that  time  is  saved  by  using  m.park.procs  and  m.rele.procs 
instead  of  m_kill_procs. 

Three  examples  are  used  to  demonstrate  this  point.  Again,  the  gettimeofday  routine  is 
used  to  test  times.  The  first  two  examples  have  a  main  process  and  two  functions,  “counts” 
and  “sayhi”.  Example  17a  executes  three  copies  of  “counts”  using  m.fork  and  then 
terminates  the  processes  with  m_kill_procs.  The  main  process  calls  gettimeofday  to 
find  the  time  before  it  executes  “sayhi”.  It  then  m.forks  “sayhi”  and  calls  gettimeofday 
again.  The  output  shows  that  it  took  approximately  .14  seconds  to  create  and  execute  the 
three  copies  of  “sayhi”. 

Example  17b  is  exactly  like  the  first  except  that  after  “counts”  is  executed,  the  processes 
are  blocked  with  a  call  to  m.park.procs.  gettimeofday  is  called  and  then  the  pro¬ 
cesses  are  released  to  execute  “sayhi”.  After  each  process  is  finished  executing  “sayhi”, 
gettimeofday  is  called  again.  In  this  case  the  output  shows  that  the  time  to  release  the 
processes  and  execute  “sayhi”  was  approximately  .02  seconds.  This  shows  that  blocking 
the  processes  is  much  quicker.  This  program  was  run  several  times  to  ensure  consistent 
results. 
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However,  were  both  subprograms  (“counts”  and  “sayhi”)  copied  in  the  initial  m.fork? 
Maybe  the  creation  of  the  processes  using  m_fork  has  more  overhead  than  copying  the 
additional  function  (“sayhi”).  Example  17c  has  a  main  process  and  one  function,  “sayhi”. 
This  program  creates  and  executes  “sayhi”  three  times.  It  then  blocks  the  processes,  gets 
the  time,  releases  the  processes,  executes  the  same  function  “sayhi”,  and  again  gets  the 
time.  In  this  program  nothing  needs  to  be  copied  on  the  second  execution  of  “sayhi”.  The 
output  shows  the  time  to  still  be  approximately  .02  seconds.  This  shows  that  the  entire 
parent  process  is  copied  to  each  new  processor  on  an  initial  m_fork. 
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/  •  Example  17a  *  / 

/ . / 

#  i  nc  I ude  <sys/time.h> 

^include  < s  t  d i o . h> 

#  i  n  c  1  u  d  e  <poral  I e l/n i c  rotask . h> 

^include  <paro I  I  e l/poro I  I e I  . h> 

#de  f  i ne  NPROCS  3 

shared  int  count, 

/»  This  program  is  used  to  show  the  time  it  takes  to 
/•  create  processes.  Two  routines  are  used  in  the  program 
/•  First,  a  number  of  proceses  are  created  to  run  the  first 
/•  routine  and  then  they  are  killed.  Then,  the  time  it 
/»  takes  to  create  new  processes  to  do  the  other  simple 
/•  routine  is  recorded. 


counts  (  ) 

i 

int  me,  i ; 

me  =  m_get_myid  (); 


/•  Who  am  I 


for  (  I  ;  i  <  NPROCS  ;  i  ++ )  j 
m_ I oc  k  (  )  ; 
count  +=  1 ; 

printf  ("process  Zd  says  count  is  S5d\n".  me,  count); 
fflush  (stdout); 
m_  u  n I oc  k  (  )  ; 


s  a  y  _  h  i  (  ) 

I 

int  me; 

me  =  m_ge  t  _my  id  (  ) 


/•  who  am  I  */ 


m_  I  oc  k  (  )  ; 

printf  ("Process  %d  says  He  I  I o\n"  ,  me); 
fflush  (stdout); 
m_unlock  (); 


main  (  ) 


struct  timeval  t,  r; 
struct  timezone  t 1  ,  r  1  ; 

count  =  0 , 

m_set_procs  (NPROCS); 
m_fork  (counts), 
m_  Hi  I  l  _  p  r  o  c  s  (); 

gettimeofdoy  (let,  &t1); 
m_fork  ( s  a  y  _  h i  )  , 
gettimeofdoy  ( tr ,  irl), 
m_kili_procs  (); 


/•  Kill  oil  children  •/ 


/*  Put  ch'ldren  to  work  •/ 


printf  ("Time  before  say_hi  is  Zd  %d\n'  ,  t  t»_se; ,  t  tv_usec) 
printf  ("Time  after  say_hi  is:  %d  %d\n'.  r  tv_sec.  r  .  t  v  _  u  s  e  c  ) 


process 
process 
process 
process 
process 
process 
process 
p  r  oc  e  s  s 
process 
Process 
Process 
Process 


soys  count 
soys  count 
soys  count 
says  count 
soys  count 
says  count 
says  count 
soys  count 
says  count 
says  Hello 
says  Hello 
says  Hello 


Time  before  say_hi  is 
Time  after  s  a  y _h i  is: 


549149061  530000 

549149061  670000 
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/•  Example  17b  »/ 

/ . * . / 


| i nc I ude  <sys/time.h> 

^include  <stdio.h> 
find  ude  <parol  I e l/mi c  rot  ask . h> 
jfinclude  <porol  lel/paral  lei  .h> 
fde f ine  NPROCS  3 

shared  int  count; 


/* 

This  program  is  used  to  record 

the  time  it 

takes 

to  e 

/• 

routine  on  existi 

ng  processes. 

First, 

the 

processes 

/* 

to  execute  a  sepo 

rate  counting 

routine 

Then  they  or 

/• 

and  then  released 

to  execute  a 

simple 

rout 

ine  w  h i 

i  c  h 

/• 

prints  o  message. 

The  "gettimeofday" 

system  call 

1  i  S 

/• 

record  the  times. 

counts  () 

! 

int  me,  i  ; 

me  =  m_get_myid  ();  /•  Who  am  I  •/ 

for  ( i =0 ;  i  <  NPROCS ;  i  ++)  | 

m_ I oc  k  (  )  ; 
count  +=  1  ; 

printf  ("process  55 d  says  count  is  55d\n”,  me,  count) 
fflush  (stdout)  ; 
m_unlock  (); 

i 

i 

s  a  y  _  h  i  (  ) 

I 

int  me; 

me  =  m_get_myid  ();  /•  who  om  1  •/ 

m_ lock  ( ) ; 

printf  ("Process  %d  says  He  I  I o\n“  ,  me); 
fflush  (stdout); 
m_u  n I oc  k  (  )  ; 

! 

main  (  ) 

I 

struct  timevol  t,  r; 
struct  timezone  t  1  ,  r  1  , 

count  =  0  . 

m_set_procs  (NPROCS), 
m_fork  (counts); 

m_park_procs  ();  /  •  Park  all  children 

gettimeofday  fit,  itl) 
m_  r  e I e_p  r  oc  s  (). 
m_fork  (say_hi  ), 
get  '  used  doy  (  i  r  ,  i  r  1  ; 
n.ki ; i.procs  (;, 

printf  ("Time  before  s  a  y  _  h  is  7.(1  %d  \  n '  .  t  tv_sec.  t 
printf  ("Time  after  s  a  y  _  h  i  is  7-d  %  d  \  n '  ,  r  tv_sec.  r 


/  •  Release  all  Children 
/•  Put  children  to  work 


x  e  c  u  t  e  a 
ore  created 
e  parked 

used  to 


•/ 

*/ 


t  v  _  u  s  e  c  ) 
t  v  _  u  s  e  c  )  , 


/  *  Exomple  17c  »/ 

/ . * . •••/ 


§  include  <sys/time.h> 

(((include  <stdio.h> 

(((include  cpora  I  I  e  l/m  i  c  r  ot  ask  .  h> 

§  include  cparal  lel/poral  lei  ,h> 

(((define  NPROCS  3 

shared  int  count; 

/•  This  program  is  used  to  record  the  time  it  takes  to  execute  a  •/ 
/«  routine  on  existing  processes.  First,  the  processes  are  created  •/ 
/•  to  execute  the  routine  " s  a  y  _  h  i  "  .  Then,  they  are  parked.  •/ 

/•  released,  and  then  they  re-execute  "soy_hiM.  I  oro  interested  in  •/ 
/•  the  time  to  re.execute  the  processes.  *  / 

s  a  y_  h  i  (  ) 

i 

int  me ; 

me  =  m_get_myid  ();  /•  who  om  I  */ 

m_ I oc  k  ( )  ; 

printf  ("Process  %d  says  He  I  I o\n" ,  me); 
fflush  (stdout); 
m_  u  n I oc  k  ( )  ; 

{ 

main  ( ) 

) 

struct  timeval  t,  r; 
struct  time  zone  t 1  .  r 1  ; 


m_set_procs  (NPROCS); 
m_  fork  (soy_hi); 

m_park_procs  ();  /*  Park  all  children  »/ 

gettimeofday  (4 t,  4t1); 
m.re I e.procs  (); 
m_  f  ork  (say_hi); 
gettimeofday  (Jcr,  4r1); 
m_kill_procs  (); 

printf  ("Time  before  say_hi  is:  %d  J5d\n",  t.tv.sec,  t.tv_usec); 
printf  ("Time  after  say_hi  is:  Zd  Zd\n",  r.tv.sec,  r.tv_usec); 

i 


Process  0  says  Hello 
Process  1  says  Hello 
Process  2  says  Hello 
Process  0  says  Hello 
Process  1  says  Hello 
Process  2  says  Hello 

Time  before  soy_hi  is  549149626  780000 
Time  after  say_hi  is:  549149628  790000 


/*  Release  all  Children  »/ 
/•  Put  children  to  work  »/ 


3.10  S_Lock  and  S_Unlock 


The  s_lock  and  s_unlock  routines  are  very  similar  to  the  m_lock  and  m_unlock  routines 
except  they  give  the  programmer  the  flexibilitj'  of  using  more  than  one  lock.  A  lock  is 
created  by  declaring  a  variable  to  be  of  type  slock_t.  The  lock  must  also  be  declared  as 
shared.  The  s_init_lock  routine  initializes  a  memory-based  lock.  Both  of  these  actions 
were  done  for  the  programmer  when  using  m_lock.  After  a  lock  is  created  and  initialized, 
a  programmer  may  use  the  lock  to  ensure  mutual  exclusion  using  the  s_lock  and  s.unlock 
routines.  This  is  done  exactly  as  before  using  mJock  and  m_unlock.  However,  now  a 
process  can  create  multiple  locks  and  use  them  in  different  contexts. 

The  following  program  increments  two  different  shared  counters.  Three  processes  are 
created  and  each  will  increment  the  two  counters  three  times.  The  main  process  begins 
by  initializing  two  locks  lockl  and  lock2.  The  main  process  then  calls  m_fork  to  create 
the  processes  and  execute  “counts”.  Each  process  gets  its  PID  and  then  enters  a  loop 
to  increment  countl.  lockl  is  used  to  ensure  mutual  exclusion  while  incrementing  countl. 
After  a  process  is  finished  with  the  first  loop,  it  enters  a  second  loop  and  begins  to  increment 
counts.  lock2  is  used  to  ensure  mutual  exclusion  while  incrementing  count2.  Notice  that 
the  addresses  of  the  locks  are  used  as  parameters  to  the  routines  s Jnit  Jock,  sJock,  and 
s_unlock.  The  DYNIX  programmer’s  manual  says  to  declare  a  lock  to  be  a  pointer  to 
type  slock_t  and  to  pass  these  pointers.  This  does  not  work.  However,  if  you  declare  the 
variables  to  be  of  type  slock_t  and  pass  their  addresses,  everything  works  just  fine. 

The  output  shows  that  each  counter  was  incremented  nine  times.  Notice  that  the  value 
of  7  is  not  printed  for  countl.  This  is  because  process  2  had  entered  the  second  loop  to 
increment  count2  and  had  overwritten  the  output  buffer  before  countl ’s  value  of  7  could 
be  printed.  The  counters  are  independent  between  the  two  loops  and  were  incremented 
correctly,  but  the  output  buffer  is  shared  between  the  two  loops.  Since  lockl  has  no  effect 
on  lock2 ,  there  is  no  mutual  exclusion  between  the  two  loops  and  output  can  be  lost.  Both 
counters  could  be  placed  in  one  loop  using  both  locks. 
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Example  18  • , 


^include  <stdio.h> 

# i nc I ude  <paral  I e l/m i c  rotask . h> 
#  i  n  c  I  u  d  e  <para  I  I  e  l/paro  I  I  e  I  .  h> 

§ de  f  i ne  NPROCS  3 

shared  int  count  1  ,  count2; 
shared  slock_t  lockl,  lock2; 


Declare  the  Locks 


This  program  illustrates  the  use  of  locking  variables  to 
ensure  mutual  exclusion.  Two  locks  are  created  by  the 
declaration  of  type  " s I o  c  k  _  t "  and  the  initialization  call 
" s_ i n i t_ I oc k " .  This  program  increments  two  counters  in 
parol  lei  .  Each  of  three  processes  will  concurrently 
increment  the  counter  and  print  its  value.  Two  critical 
regions  are  implemented  with  the  two  locks  to  ensure  that 
the  incrementing  of  a  counter  and  printing  its  value 
appear  as  atomic  instructions. 


int  me ,  i ; 

me  =  m_get_myid  (); 


/•  Who  am  I  */ 


for  (  i=0;  i  <  NPROCS;  i++)  j 

s_lock  (Jclockl);  /•  Lock  the  criticol  region  •/ 

count  1  +=  1  ; 

printf  ("process  %d  soys  count  1  is  %d\n",  me,  count  1  ) ; 
fflush  (stdout); 

s  _  u  n  I  o  c  k  ( 1  I o  c  k 1  )  ;  /  *  Unlock  the  critical  region  •/ 


for  (i=0;  i  <  NPROCS;  i++)  j 

s_ I o  c  k  (  Jt  l  oc  k  2  )  ;  /•  Lock  the  critical  region  •/ 

c  o  u  n  t  2  +=  1  ; 

printf  ("process  Zti  says  count2  is  %d\n",  me,  count  2  )  ; 
fflush  (stdout); 


s_  unlock  ( &  I oc  k  2  ) 


/•  Unlock  the  criticol  region  »/ 


ma  in  (  ) 

I 


s_init_lock  ( 4  I oc k 1  , 4  I oc k 2 ) 
c  o  u  n  t  1  =  0  ; 
count  2  =  0, 

m_set_procs  (NPROCS); 
m_fork  (counts); 
m_kill_procs  (); 

pr  r,  t  <  ("counter  over\n"), 


/•  initialize  the  locks  •/ 


fi’  n"  ti*  !»• 


process  2  soys  count  1  is  1 
process  1  says  countl  is  2 
process  0  says  countl  is  3 
process  2  says  countl  is  4 
process  1  says  countl  is  5 
process  2  soys  countl  is  6 
process  2  says  count2  is  1 
process  1  says  countl  is  8 
process  2  says  count2  is  2 
process  0  says  countl  is  9 
process  1  says  count2  is  3 
process  2  says  count2  is  4 
process  0  soys  count2  is  5 
process  0  says  count2  is  6 
process  1  says  count2  is  7 
process  0  says  count2  is  8 
process  1  soys  count2  is  9 
counter  over 


3.11  SJnit -Barrier  and  S_Wait_Barrier 


The  s.init -barrier  routine  initializes  a  barrier  as  a  rendezvous  point  for  N  processes,  where 
N  is  passed  as  a  parameter  to  s_init_barrier.  The  s -wait-barrier  routine  delays  each  calling 
process  in  a  busy- wait  spin  until  exactly  N  processes  have  called  s_ wait -barrier.  In  C, 
a  barrier  is  declared  as  a  shared  data  structure  of  type  sbarrier_t.  The  function  of  the 
s_wait_barrier  routine  is  exactly  like  the  m_sync  routine  with  the  added  flexibility  of 
specifying  the  number  of  processes  to  synchronize.  It  also  allows  the  creation  of  multiple 
barriers. 

The  following  program  again  increments  two  shared  counters,  countl  and  counts.  The 
main  process  will  create  and  initialize  two  locks  and  two  barriers;  one  for  each  counter. 
The  main  process  creates  three  processes  to  execute  “counts”.  Each  process  gets  its  PID 
and  enters  an  outer  loop.  The  outer  loop  is  designed  to  demonstrate  the  use  of  the  barriers. 
Again,  I  have  two  inner  loops  to  increment  each  counter  separately,  lockl  and  lock2  provide 
mutual  exclusion  for  countl  and  counts ,  respectively.  The  main  process  has  initialized  each 
barrier  to  wait  for  three  processes  (the  number  created).  Each  process  calls  s_wait_barrier 
between  each  inner  loop.  All  processes  synchronize  on  barrier  1  after  incrementing  countl. 
All  processes  synchronize  on  barrier 2  after  incrementing  count2. 

The  output  shows  that  each  counter  was  incremented  27  times,  nine  times  per  outer  loop. 
Notice  that  each  counter  is  fully  incremented  and  printed  before  the  next  loop  has  begun. 
This  time  no  output  is  lost. 


/•  Example  19  «/ 

/ . •*»*/ 


# i n  c I u  de  < s  t  d i o . h> 

find  ude  <  p  a  r  o  I  I  e  I  /m  i  c  r  o  t  a  s  k  .  h> 

^include  <paral  lel/paral  lei  .h> 

#dc  f  i ne  NPROCS  3 

shared  int  count  1  ,  count2; 

shared  sbarrier_t  barrierl,  bar  r i e  r2  ;  /»  Declare  the  Barriers  */ 

shared  slock_t  lockl.  lock2;  /*  Declare  the  Locks  •/ 


/•  This  ;  r  og  r am  illustrates  the  use  of  locking  variables  to  •/ 
/»  ensure  mutual  exclusion.  Two  locks  are  erected  by  the  •/ 
/ •  declaration  of  type  "slock_t"  and  the  initialization  call  •/ 
/•  " s_ i n  i  t_ I oc k  "  .  This  program  increments  two  counters  in  •/ 
/•  parallel.  Each  of  three  processes  will  concurrently  *  / 
/•  increment  the  counter  and  print  its  value.  Two  critical  •/ 
/»  regions  are  implemented  with  the  two  locks  to  ensure  that  •/ 
/•  the  incrementing  of  a  counter  and  printing  its  value  •/ 
/•  appear  as  atomic  instructions.  •/ 
/•  Two  barriers  are  declared  by  the  type  "  s  b  a  r  r  i  e  r  _  t  "  and  •/ 
/»  initialized  by  the  call  to  "s_init_barrier".  The  two  *  / 
/•  barriers  are  used  to  synchronize  all  the  processes  offer  •/ 
/•  incrementing  each  counter.  The  call  to  s_*o i  t_bar  r ie  r  •/ 
/•  will  block  the  calling  process  until  NPROCS  processes  •/ 
/•  have  made  the  cal  I  .  •/ 


counts  ( ) 

f 


int  me,  i ,  j  ; 

me  =  m_get_myid  (); 

for  ( j -0 ;  j  <  NPROCS,  j++)  | 

for  ( i =0 ;  i  <  NPROCS ;  i ++ ) 
s_lock  (Jclockl); 
count',  +-  1  ; 

printf  ("process  55d  soys 
fflush  (stdout  )  ; 
s.unlock  (iclockl); 

\ 

s_wait_barrier  (4bor  r i erl ) ; 

for  (i=0;  i  <  NPROCS;  i++) 
s_ I oc  k  (  4  I  oc  k  2  )  ; 
c  o  u  n  t  2  +=  1  ; 

printf  ("process  55 d  says 
fflush  (stdout); 
s_un I oc  k  ( 4  I oc  k  2  )  ; 

i 

s_woit_barrier  (iba  r  r i er2)  ; 


/*  Who  am  I  »/ 

\ 

/*  Lock  the  critical  region  • 
countl  is  %d\n",  me,  count!); 

/*  Unlock  the  critical  region 
/•  All  processes  synchronize 

5 

/•  Lock  the  critical  region 
count2  is  55d\n",  me,  count2), 

/»  Unlock  the  critical  region 
/*  All  processes  synchronize 


ma  in  (  ) 

I 


S  _  i  n  i 

t  _  b  o  r  r 

1  e  r 

(  4  b  o  r  r  i  e  r  1  , 

NPROCS)  , 

/• 

initialize  the  barriers  • 

S.iri 

t  _  b  o  r  r 

1  e  r 

(4ba  '  r  i e  r 2 , 

NPROCS)  , 

S_  i  r  ; 

t  _  lock 

<  *  1 

OC  1  1  1  , 

/* 

initialize  the  locks  • / 

s  _  i  n  i 

t  _  l oc  k 

(*l 

0  C  k  2  )  . 

count’  =  0 , 
c  o  u  n  t  2  =  0  , 


m_set_procs  (NPROCS; 
m_fork  (counts). 


m_k i  I  I _p  r  oc  s  (); 

printf  ("counter  over\n") 


f 


process  0  says 
process  2  says 
process  1  says 
process  0  says 
process  2  says 
process  1  says 
process  0  says 
process  2  says 
process  1  says 
process  0  soys 
process  2  says 
process  1  says 
process  0  soys 
process  1  says 
process  2  says 
process  1  says 
process  0  says 
process  2  soys 
process  t  says 
process  2  says 
process  1  soys 
process  0  says 
process  2  says 
process  1  says 
process  0  says 
process  2  says 
process  0  says 
process  1  says 
process  0  says 
process  2  says 
process  1  says 
process  0  says 
process  2  says 
process  1  says 
process  0  says 
process  2  says 
process  1  says 
process  2  says 
process  0  says 
process  1  says 
process  0  says 
process  2  says 
process  1  says 
process  0  says 
process  2  says 
process  0  says 
process  2  says 
process  1  says 
process  0  says 
process  2  says 
process  1  says 
process  0  says 
process  2  soys 
process  1  says 
counter  over 
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3.12  M.Single  and  M_Multi 

How  can  a  programmer  print  out  a  message  within  a  m_forked  subprogram?  Not  every 
process  should  print  the  message.  How  can  you  perform  any  type  of  1/0  only  once  (such 
as  reading  a  counter  value)?  The  subprogram  could  be  written  so  that  only  a  specific 
process  (based  on  PID)  performs  the  read  while  the  others  wait.  The  m_single  and 
m_multi  routines  suspend  the  execution  of  all  child  processes  while  the  parent  (process 
0)  performs  some  sequential  task  (I/O).  The  m_single  places  the  children  in  a  spin  while 
the  parent  continues  execution.  The  parent  calls  m_multi  to  resume  the  execution  of  the 
children.  The  children  do  not  execute  the  code  between  the  call  to  m_single  and  the  call 
to  m_multi. 

Example  20  performs  the  same  function  as  the  previous  program.  It  increments  two  shared 
counters.  Again  two  locks  and  two  barriers  are  used  to  ensure  mutual  exclusion  and 
synchronization.  However,  this  program  prints  a  message  between  each  iteration  of  the 
outer  loop.  Only  one  process  should  print  the  message  (the  parent).  The  print  command  is 
encapsulated  within  an  m_single  /  m_multi  block.  The  output  shows  that  the  iteration 
number  was  printed  only  once  (by  the  parent)  after  each  iteration  of  the  outer  loop. 
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Example  20 


finclude  <  s  t  d i o , h> 

| i nc I ude  < pa r a  I  I  e  I /m i c r o t a s k  .  h > 
^include  <pa  ro  I  I e l/parol  I  e  I  .  h> 


#de  f  i ne  NPROCS  3 


shared  int  count  1  ,  count2; 

shared  sbar  r i er_t  barrierl,  ba  r  r i e  r2  ; 

shared  s  I  ock.t  loukl,  lock2; 


Declore  the  Barriers 
Declare  the  Locks  */ 


This  program  illustrates  the  use  of  locking  variables  to 
ensure  mutual  exclusion.  Two  locks  are  created  by  the 
declaration  of  type  " s I oc  k_t "  and  the  initialization  call 
" s_ i n i  t_  I  oc k  "  .  This  program  increments  two  counters  in 
parallel  Each  of  three  processes  will  concurrently 
increment  the  counter  and  print  its  value.  Two  critical 


regions  ore  implemented  with  the  two  locks  to  ensure  that  »/ 


the  incrementing  of  a  counter  and  printing  its  value 
appear  os  atonic  instructions. 

Two  barriers  are  declared  by  the  type  "sbarrier_t"  and 
initialized  by  the  call  to  "s_init_borrier".  The  two 
barriers  are  used  to  synchronize  all  the  processes  after 
incrementing  each  counter.  The  call  to  s_woit_barrier 
will  block  the  calling  process  until  NPROCS  processes 
have  made  the  call. 

The  m_single  and  m_multi  system  calls  ore  used  to  allow 
the  parent  process  to  print  a  message.  These  calls 
suspend  all  processes  except  the  parent  and  only  the 
parent  is  allowed  into  this  critical  region. 


counts  (  ) 

I 


int  me,  i ,  j  ; 

me  =  m_get_myid  (); 


/*  Who  am  I  •/ 


for  ( j  =0 ;  j  <  NPROCS,  j ++ )  J 

for  ( i =0 ;  i  <  NPROCS ;  i  ++)  } 

s_lock  ( 4  I o  c  k 1  )  ;  /•  Lock  the  critical  region  •/ 

count  1  +=  1  ; 

printf  ("process  %d  says  count!  is  55d\n”,  me,  count  1  )  ; 
fflush  (stdout), 

s_unlock  ( 4  I oc  k 1 )  ;  /•  Unlock  the  critical  region  *  / 

I 

s_woit_barrier  (4bar  r i e  r 1 ) ;  /•  All  processes  synchronize  *  / 


for  (  I =0  ;  i  <  NPROCS ;  i ++)  ) 

s_lock  (4lock2),  /•  Lock  the  critical  region  •/ 

count2  +=  1; 

printf  ("process  %d  says  count2  is  %d\n".  me,  count2); 
fflush  (stdout), 

s_un I ock  (4lock2);  /•  Unlock  the  critical  region  »/ 


s_woit_ barrier  (4bar  r i er2) , 


/♦  AM  processes  synchronize  •/ 


/•  Parent  process  prints  a  message  •/ 


m  _  s  i  n  g  i  e  (  )  ; 

print*  (  "\nl terol  ion  %  d  Coup  l  et  ed\n\n"  1  +  1), 
fflush  (stdout), 
m  m  u  I  1  (  )  , 


ma-n  |  ! 
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3.13  M_Next 


The  m_next  routine  increments  a  global  counter.  The  counter  is  initialized  to  zero  each 
time  the  m_fork,  m_single,  or  m_sync  routines  are  called.  You  may  obtain  the  value  of 
the  counter  simply  by  calling  m_next  which  returns  its  integer  value.  Each  time  m_next 
is  called,  it  returns  its  current  value  and  then  increments  the  counter.  These  two  steps 
are  accomplished  atomically  to  ensure  that  no  two  processes  will  see  the  same  value  of  the 
counter. 

Example  21  illustrates  the  use  of  the  m_next  routine.  In  this  example,  “counts”  is  called 
to  increment  a  shared  counter  nine  times.  The  main  routine  creates  three  processes  to 
execute  “counts”  in  parallel.  In  this  particular  example,  the  main  routine  does  not  care 
how  many  times  a  process  increments  the  counter,  just  as  long  as  the  counter  is  incremented 
nine  times.  Each  process  does  not  know  how  many  times  it  should  increment  the  ct  unter. 
It  only  knows  the  number  of  times  the  counter  should  be  incremented,  nine.  By  calling 
m_next  before  incrementing  the  counter,  each  process  can  see  if  the  counter  has  been 
incremented  the  correct  number  of  times.  If  the  counter  has  not  been  incremented  nine 
times,  increment  the  counter,  otherwise  return.  The  output  shows  that  the  counter  was 
incremented  nine  times.  However,  each  process  did  not  increment  the  counter  three  times 
as  in  previous  examples.  Process  1  incremented  the  counter  four  times.  The  m_next 
routine  is  most  useful  for  dynamic  applications.  For  example,  an  application  where  each 
process  performs  the  same  task  on  a  set  of  data,  but  the  amount  of  data  is  not  known  until 
run  time. 


/*♦**• . / 

/»  Example  21  •/ 

/ . / 


^include  <stdio.h> 

finclude  <pa  ra I  I e I/m i c  rotask . h> 

f  Include  <paral  I e l/paral  lei  .  h  > 

#de  fine  NPROCS  3 
#  d  e  f  i  n  e  N  9 
shared  int  count; 

/•  This  program  illustrates  the  use  of  m_lock.  The  program  counts  •/ 
/•  by  increasing  the  value  of  a  variable  in  parallel.  The  program  •/ 
/»  maintains  mutual  exclusion  with  a  call  to  m_ I o  c  k  .  Each  copy  of  •/ 


/»  the  procedure  increments  the  shared  variable  "count"  •/ 
/•  concurrently,  and  therefore,  mutual  exclusion  is  required.  •/ 
/•  The  program  also  shows  how  to  use  the  globol  counter  m_next.  •/ 
/•  Each  time  m_next  is  called,  its  v  o  I  u  »  is  incremented.  Eoch  •/ 
/»  process  will  increment  count  until  it  has  been  incremented  »/ 
/•  nine  t imes.  »/ 


counts  () 
int  me; 

me=m_get_myid();  /*  Get  my  Pit  »/ 

while  ( m  _  r,  ext  ()  <=  N)  } 
m_ lock  (  )  ; 
count  +=  1  ; 

printf  ("process  %d  says  count  is  %d\n",  me,  count); 
fflush  (stdout); 
ro  unlock  (  )  ; 

i 

i 

main  (  ) 

i 

count  =  0 ; 

m_set_procs  (NPROCS);  /•  Create  NPROCS  processes  •/ 

n_fork  (counts); 

m_kill_procs  ();  /•  Terminate  all  Processes  except  Parent  »/ 

printf  ("counter  over\n"); 


I 


process 

0 

soys 

count 

i  s 

1 

process 

1 

says 

count 

i  s 

2 

process 

2 

says 

count 

i  s 

3 

process 

1 

says 

count 

i  s 

4 

process 

0 

says 

count 

i  s 

5 

process 

1 

says 

c  o  u  n 

i  s 

6 

process 

0 

soys 
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t  s 

7 

process 

2 

says 

count 

i  S 

e 

process 

1 

says 

count 

1  s 

9 

counter 

over 
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3.14  Matrix  Multiply 

So  far  only  very  simple  (and  somewhat  useless)  programs  have  been  used  to  illustrate  the 
function  of  the  Parallel  Programming  Library.  Example  22  demonstrates  “Data  Partition¬ 
ing”.  The  program  is  to  multiply  two  six  by  six  matrices.  Each  row  of  matrix  A  will  be 
multiplied  by  every  column  of  matrix  B  to  produce  a  new  row  in  matrix  C.  It  appears  very 
natural  to  partition  the  data  by  rows.  Therefore,  “row”  is  a  routine  that  will  multiply  one 
row  of  matrix  A  by  every  column  in  matrix  B  to  produce  a  new  row  in  matrix  C. 

The  program  declares  each  matrix  A,  B,  and  C  to  be  shared.  The  main  process  then  calls 
init ..matrices  to  read  in  matrix  A  and  B.  It  sets  the  number  of  processes  to  be  created 
to  six  by  using  the  call  to  m_set_procs.  It  then  calls  m_fork  to  create  the  processes  and 
to  have  each  execute  the  function  “row”.  Six  processes  were  created,  one  for  each  row  in 
Matrix  C. 


Upon  executing  “row”,  each  process  immediately  gets  its  PID  using  m_get_myid.  Re¬ 
member  that  the  PIDs  range  from  0  to  5.  The  row  indices  of  matrix  C  also  run  from  0 
to  5.  This  is  more  than  a  coincidence.  Each  process  i  will  produce  row  i  in  matrix  C  by 
multiplying  row  i  in  matrix  A  by  every  column  in  matrix  B. 

After  each  process  is  finished,  the  main  process  terminates  all  the  child  processes  (executing 
“row”)  and  prints  out  the  results.  It  would  not  have  accomplished  anything  to  have  each 
process  print  out  its  own  results,  since  the  output  must  be  sequential. 


. . . 

/  *  Example  22  •/ 

/•  Matrix  Multiply  •/ 

/ . / 

jlinclude  <stdio.h> 

finclude  <paral  I e I/m i c  r ot  ask . h> 

jjfinclude  < pa r a  I  I e I /pa r a  I  I e I  . h > 

#  d  e  f  i  n  e  N  6 


shared  int  c [ N ] [ N ]  ,  a [ N ] [ N  ]  ,  b [ N ] [ N  ]  ; 

/♦  This  procedure  multiplies  rox  i  of  matrix  A  by 

/•  each  column  of  matrix  B  and  stores  the  result 

/•  in  row  i  of  matrix  C. 


void 
row  (  ) 

\ 

int  i  .  j  .  k  ; 


=  m_g e  t  _m  y id  (  )  ; 


/•  Which  row  do  I  multiply  *  / 


.f  o  r  (  j  =  0  ;  j<N;  j ++ )  } 

c[i][j]  =  0i 

f  o  r ( k  =  0 ;  k<N ;  k  +  + ) 

c [ i ] [ j ]  +=  a[i][k]  •  b [ k ] [ j ] ; 

I 


/•  This  procedure  reads  in  two  N  by  N  matrices  •/ 
void 

i n i  t_mat  r ices  (  ) 

i 

int  i  ,  j  ; 

for  (  i  =0  ,  i <N ;  i ++ )  J 

scant  (  "%d%d7.d%d%d7.d7.d%d%d%d%d%d"  ,  *a[i)[0],  4a[i][l),  4  a  [  i  )  [  2  ]  . 

Sea[i][3],  4a[i][4],  4a[i][5],  «cb[.][0],  *b[.][1],  4b[,][2] 
*b[i][3],  4b  [ i j  [  4  ] ,  4b[i][5]); 

I 


This  program  multiplies  two  N  by  N  matrices,  A  ond  B  to  get 
matrix  C  The  program  is  executed  in  parallel  by  creating 
N  processes  with  m.fork  Each  child  process  will  multiply 
row  i  of  matrix  A  by  eoch  column  of  matrix  B  to  get  row  i  of 
matrix  C.  where  i  s  the  PIO  of  the  process  AM  three 
Matrices  are  in  shared  memory  for  each  process  to  occess 
Since  eoch  process  is  writing  to  a  separate  row  in  C,  no 
synchronization  tc  occess  memory  is  necessary 


m  a  i  n  (  ) 


void  in. t_mat rices  (),  row  (), 
'  n  t  i  ,  j  , 

init_matrices  (). 

m_set_procs  (  N  ) 
m  _  t  o  r  k  (row/. 
m_kill_procs  (). 

/*  pr  nt  out  each  matrix  •/ 


/•  read  in  matrices  •/ 


/•  create  6  processes  •/ 


-V  A  _%  M _%  ■  A.  L.'w  .  V  _  «r  .  «  .V  _V  .  V  .  -  ,  W  .V 


p  r i n t  f  ( "  MATR I  X  A 

printf  ( “  _ 

for  (i=0;  i  <  N  ;  i +  + )  j 

for  ( j  =0 ;  j  <N ;  j ++ ) 
printf  ( “%3d  " .  a [ 
printf  ("  "); 

for  ( j =0 ;  j  <N ;  j  ++ ) 
printf  (  "%3d  ",  b[ 
printf  ( "  "); 

for  ( j  =0 ;  j  <N ;  j  ++ ) 
printf("%3d  ",  c[ 
printf("\n"); 


MATRIX  A 


2  2  2  2  2  2 

3  3  3  3  3  3 

4  4  4  4  4  4 

5  5  5  5  5  5 

6  6  6  6  6  6 

7  7  7  7  7  7 


MATRIX  B 


i  ]  [  j  ] )  : 


](  j]): 


MATRIX  B 


3  3  3  3  3  3 

4  4  4  4  4  4 

5  5  5  5  5  5 

6  6  6  6  6  6 

7  7  7  7  7  7 

8  8  8  8  8  8 


MATR I  X  C\n " )  ; 
_ \n\n " )  ; 


MATRIX  C 


66 

66 

66 

66 

66 

66 

99 

99 

99 

99 

99 

99 

1  32 

1  32 

1  32 

1  32 

132 

1  32 

1  65 

1  65 

165 

1  65 

165 

1  65 

198 

1  98 

198 

198 

198 

1  98 

231 

231 

231 

231 

231 

231 

V 


wv 
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3.15  Shared  Memory 

Shared  memory  is  a  very  effective  and  efficient  mechanism  for  communication.  Any  variable 
which  is  shared  between  processes  and  changed  by  those  processes  is  a  type  of  communi¬ 
cation.  The  difficulty  of  shared  memory  is  mutual  exclusion.  This  means  that  only  one 
process  should  update  a  shared  data  item  at  one  time.  Otherwise,  the  processes  could 
produce  incorrect  results.  Example  23  illustrates  how  shared  memory  can  be  used  for  a 
more  explicit  type  of  communication. 

This  program  creates  three  processes.  The  three  processes  are  arranged  logically  in  a  circle. 
In  other  words,  process  i  can  only  talk  to  process  i  +  1  and  i  —  1  (the  process  on  its  left 
and  right).  The  process  index  will  be  its  PID.  Each  process  will  have  a  mailbox.  A  process 
can  only  write  to  its  mailbox,  but  can  read  from  any  mailbox.  The  processes  are  to  pass  a 
number  from  one  process  to  another  around  the  circle.  After  the  number  has  been  passed 
in  a  complete  circle,  the  parent  will  print  the  number  out. 

The  main  program  begins  by  initializing  each  mailbox  to  0  which  designates  an  empty 
mailbox.  The  mailboxes  are  declared  as  an  array  in  shared  memory,  so  that  each  process 
can  use  indices  to  read  the  mailboxes.  The  main  process  then  creates  three  processes  to 
execute  “nodes”.  In  “nodes”,  each  process  immediately  gets  its  PID  and  computes  its 
neighbor’s  indices.  The  parent  process  ( my.node  =  0)  reads  in  the  value  of  the  number  to 
pass.  It  then  places  the  number  in  its  mailbox  for  its  left  neighbor  to  read.  The  parent 
process  then  spins  while  its  right  neighbor’s  mailbox  is  empty  (0).  Each  child  process  does 
the  same.  Once  a  process  can  read  its  neighbor’s  mailbox,  it  places  the  number  in  its  own 
mailbox  for  another  process  to  read.  When  the  parent  receives  the  number,  it  prints  the 
value.  Each  process  prints  the  PID  of  the  process  which  will  read  the  number  next. 

This  program  shows  that  not  only  can  a  shared  variable  be  used  to  pass  information,  but 
that  it  can  be  the  foundation  for  synchronization  (the  busy-waits). 
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/ . / 

/  *  E  x omp  I  e  23  */ 

/»  Mailboxes  •/ 

/*««*•••**»*»»»*,/ 

| i nc I ude  <s  t  d i o . h> 

§  include  <pora I  I e l/m i crotask . h> 

^include  <pa r a  I  I  e I /pa r a  I  I e I  . h> 

#de  f  i ne  NPROCS  3 


shared  int  m bo x [ NPROCS ] ; 

/»  Each  process  runs  this  routine.  The  node  (process)  will  pass  »/ 

/  *  the  Card  by  placing  it  in  its  mailbox.  Each  Node  will  read  *  / 

/•  the  card  from  the  mailbox  on  its  left.  Node  0  which  is  »/ 

/•  actually  the  parent  process,  starts  by  reading  in  the  cord  to  •/ 

/•  pass  around  the  circle.  •/ 

/*  Synchronization  is  accomplished  by  each  Node  busy-waiting  •/ 

/  *  until  its  neighbor's  mailbox  isnotempty.  •/ 

nodes  (  ) 

i 

int  card; 

int  my_node,  neighbor,  next_node; 

my_node  =  m_get_myid  ();  /*  get  my  process  id  */ 

neighbor  =  (my_node  +  (NPROCS  -  1))  %  NPROCS;  /»  who  is  my  neighbor  »/ 
next_node  =  (my_node  +  1)  %  NPROCS;  /*  who  reads  my  ma i Ibox  •/ 

if  (my_node  ==  0 )  j 

printf  ("Enter  the  Card  to  Pass  (1-10):  "); 

scant  ("%d",  tcard) ; 

printf  ("\nCord  to  pass  is  55d\n",  card); 
fflush  (stdout); 

/•  Place  card  in  my  mailbox  for  my  neighbor  to  reod  */ 

printf  ("Node  Zd  passes  % d  to  Node  %d\n",  my_node,  card,  next_node); 

fflush  (stdout); 

mb o x [ my _ node ]  =  cord; 

while  (mbox[neighbor]  ==  0)  ;  /•  Busy-Wait  until  cord  is  in  mailbox  »/ 
/*  Read  mailbox  and  print  card  •/ 

printf  ("\n\nCord  Passed  through  All  Nodes,  Returned  value  is  %d\n", 
mbox[neighbor]); 
fflush  (stdout), 

i 

else  j  /•  if  I  am  not  the  parent  process  •/ 

wh.le  (mbox[neighbor]  ==  0)  ;  /•  Busy-Wait  until  mailbox  not  empty  •/ 

printf  ("Node  Zd  passes  Zd  to  Node  %d\n",  my_node,  m bo x [ n e i g b b o r ] , 
next_node) , 
fflush  (stdout). 

m b o x [ my _ n od e  ]  =  m b o x [ n e i g h b o r ]  , 

( 


/•  initialize  boxes 


for  ( i=0;  i  <  NPROCS;  i++)  j 
m  bo  x  [  i  ]  =  0; 

i 


m_set_procs  (NPROCS); 
m_  fork  (nodes); 
m_k i  I  l_p  rocs  (  )  ; 


/•  set  number  of  players  »/ 
/•  start  the  game  •/ 
/•  game  is  o»er  */ 


Enter  the  Card  to  Pass  (1-10); 
Card  to  pass  is  5 

Node  0  passes  5  to  Node  1 

Node  1  passes  5  to  Node  2 

Node  2  passes  5  to  Node  0 


Card  Passed  through  All  Nodes.  Returned  value  is  5 


4  Cobegin— Coend  Implementation 


Section  3  introduced  both  the  fork  and  m_fork  routines  and  demonstrated  how  each  is 
used  for  process  creation.  The  fork,  exit,  and  wait  routines,  when  used  together,  provide 
for  process  creation,  termination,  and  synchronization.  The  problem  with  these  routines 
is  that  they  can  become  confusing  to  the  programmer.  Omission  and  commission  errors 
are  also  a  threat.  The  m_fork  routine  is  a  higher  level  process  creation  mechanism.  It 
names  the  specific  routine  to  be  placed  in  execution  and  provides  for  process  termination. 
However,  m_fork  can  only  create  a  limited  number  of  processes  (the  number  of  available 
processors  minus  one)  and  each  process  will  execute  the  same  routine.  This  is  satisfactory 
since  m_fork  was  designed  for  data  partitioning. 

We  require  a  mechanism  which  will  allow  a  programmer  to  create  as  many  processes  as 
the  operating  system  allows.  This  mechanism  should  also  allow  the  processes  to  execute 
different  sections  of  code  to  support  both  data  partitioning  and  functional  partitioning. 
Each  of  these  requirements  are  met  by  the  construct  “cobegin-coend”.  A  cobegin-coend 
construct  is  a  block  of  code  which  is  a  structured  method  of  creating  processes.  The 
cobegin-coend  structure  was  derived  from  Dijkstra’s  “Parbegin-Parend”  construct.  The 
syntax  and  semantics  of  the  cobegin-coend  are  as  follows, 
cobegin 

statement  1 
statement  2 
statement  3 

statement  N 

coend 


Each  statement  within  the  cobegin-coend  block  is  executed  concurrently  and  may  be  any  ' 

valid  C  statement  including  function  calls  or  block  statements.  The  execution  of  code  after  ] 

the  cobegin-coend  block  will  not  proceed  until  every  statement  within  the  cobegin-coend  ! 

block  has  terminated.  The  cobegin-coend  automatically  provides  for  process  creation  ' 

and  termination  while  retaining  much  of  the  flexibility  of  the  fork  routine.  This  higher  ' 

level  construct  allows  programmers  to  easily  structure  concurrent  programs.  A  reader  of 
a  program  containing  this  construct  can  clearly  identify  all  tasks  marked  for  concurrent 
execution.  Also,  this  construct  is  structured  (one  way  in  and  one  way  out)  and  can  easily 
be  nested.  However,  the  cobegin-coend  is  not  all  powerful.  Its  major  weakness  is  that  it 
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can  not  handle  dynamic  applications.  For  example,  an  application  which  does  not  know 
how  many  separate  processes  it  requires  until  run  time. 


4.1  Precompiler  Logic 


A  precompiler  was  written  to  implement  the  cobegin-coend  construct.  The  precompiler 
was  written  in  C  and  prepares  a  C  program  which  contains  cobegin-coend  blocks  for  the  C 
compiler.  The  function  of  the  precompiler  is  to  find  cobegin-coend  blocks  and  to  transform 
each  block  into  a  set  of  routines  vrhich  provide  for  process  creation,  termination,  and 
synchronization.  The  fork,  exit,  and  wait  routines  are  used  to  provide  this  functionality. 
Each  of  these  routines  is  found  in  Unix,  as  well  as  DYNIX,  which  adds  to  the  portability 
of  the  precompiler.  The  effect  of  the  precompiler  generated  code  is  that  each  statement 
within  the  cobegin-coend  block  will  be  forked  by  the  parent  process  and  executed  by  a 
child  process  (process  creation).  After  executing  a  statement,  each  child  process  will  exit 
(process  termination).  At  the  end  of  the  cobegin-coend  block,  the  parent  will  call  the  wait 
routine  for  each  child  created  (process  synchronization).  An  example  of  the  generated  code 
follows: 

Before  Precompilation  After  Precompilation 

cobegin  pid  =  fork  (); 

statement  1  if  (pid  !=  0) 

statement  2  pidarray[jj++]  =  pid; 

coend  if  (pid  ==  0)  { 

statement  1 
exit  (0);  } 
pid  =  fork  (); 
if  (pid  !=  0) 

pidarray[jj++]  =  pid; 
if  (pid  ==  0)  { 
statement  2 
exit  (0);  } 

for  (ii=0;  ii<2;  ii++)  { 

pid  =  wait  (^status); 
if  (status)  { 

jj  =  0; 

while  (pid  !=  pidarray[jj]) 

jj++; 

printf  (“Error  on  Stmt  %d  in  cobegin  block”,  jj); 
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The  code  generated  after  precompilation  shows  that  a  fork  was  performed  for  each  state¬ 
ment.  If  the  PID  (process  id)  is  not  zero  (designating  the  parent),  add  the  PID  to  an  array 
of  PIDs.  If  the  PID  is  zero  (designating  the  child),  execute  the  statement  and  then  exit. 
At  the  end  of  the  cobegin-coend  block,  the  parent  performs  a  wait  for  each  child.  The 
parent  tests  the  status  of  the  terminating  child  and  will  print  an  error  message  if  the  child 
terminated  writh  an  error  code.  The  error  message  contains  the  statement  number  of  the 
statement  the  child  executed  relative  to  the  beginning  of  the  cobegin-coend  block.  The 
reason  for  printing  this  error  message  is  to  aid  the  programmer  in  debugging  a  program  in 
a  concurrent  environment.  The  array  pidarray  and  the  integers  ii,  jj,  and  pid  are  inserted 
for  the  programmer  in  order  to  keep  the  implementation  of  the  cobegin-coend  construct 
transparent.  Notice  that  the  parent  process  creates  a  child  for  each  statement  and  does 
not  execute  one  of  the  statements  itself.  This  decision  was  for  simplicity.  The  precompiler 
would  need  to  read  the  source  code  twice  or  would  need  to  store  full  statements  in  memory 
in  order  to  allow  the  parent  process  to  execute  one  of  the  statements.  This  is  because  the 
precompiler  reads  one  line  at  a  time  and  has  no  look  ahead  capability.  The  precompiler 
can  not  predict  the  length  of  a  statement. 

Appendix  A  contains  the  source  code  for  the  precompiler.  The  function  of  the  precompiler 
is  simple.  The  most  difficult  aspect  of  the  precompiler  is  the  recognition  and  separation  of 
C  statements.  The  statement  within  the  cobegin-coend  block  can  be  any  valid  C  statement 
including  blocks  of  code  such  as  for,  while,  and  do  statements.  A  stack  is  used  to  separate 
the  statements  within  the  cobegin-coend  block.  A  user  may  invoke  the  precompiler  by  the 
command  cobegin  filename.  The  precompiler  will  first  check  to  see  that  the  user  has  entered 
the  filename  of  a  C  source  file.  It  then  attempts  to  open  the  file  and  to  create  two  more 
files,  a  new  source  file,  and  a  trace  file.  The  new  source  file  will  contain  the  program  code 
after  precompilation.  The  trace  file  will  contain  a  trace  of  all  stack  operations  performed 
by  the  precompiler.  The  names  of  these  two  files  are  based  on  the  name  of  the  original 
source  file.  If  the  original  source  file’s  name  is  xxxx.c,  the  new  source  file  will  be  named 
xxxxp.c,  and  the  trace  file  will  be  named  xxxxt.d.  The  trace  file  will  only  be  retained  if 
an  error  occurs  during  precompilation. 

The  precompiler  allows  up  to  six  source  files  to  be  entered  by  the  user  at  a  time.  The 
purpose  of  the  “main”  routine  is  to  read  the  command  line  arguments  and  to  create  a 
process  for  each  entered  file.  The  “main”  routine  calls  the  function  “find_block”  for  each 
file  entered.  “find_block”  creates  and  opens  all  required  files  and  begins  a  search  for  any 
cobegin-coend  block  in  the  source  file.  The  keywords  “cobegin”  and  “coend”  designate  a 
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cobegin-coend  block  and  each  must  be  in  lower  case  and  on  a  line  by  themselves.  These 
requirements  do  not  effect  the  programmer  and  ease  the  search  for  the  cobegin-coend 
blocks.  “find-block”  will  call  the  function  “forkstmts”  for  each  cobegin-coend  block  found. 

“find_block”  will  also  insert  the  declarations  for  the  variables  ii,  jj,  pid,  and  pidarray.  These 
variables  are  placed  outside  the  source’s  “main”  routine.  This  was  done  because  the  “main” 
routine  is  easjr  to  find  and  every  C  program  must  have  this  routine.  The  precompiler 
supports  separate  compilation  since  only  routines  which  contain  cobegin-coend  blocks  need 
to  be  precompiled.  However,  the  “main”  routine  must  always  be  precompiled,  “find-block” 
will  close  all  files  after  the  source  program  has  been  precompiled. 

The  function  “forkstmts”  is  the  heart  of  the  precompiler.  Its  function  is  to  separate  the 
statements  of  the  cobegin-coend  block  and  to  call  the  appropriate  functions  for  inserting 
any  required  code.  The  functions  “prforks”,  “prwaits”,  and  “printexit”  are  used  to  insert 
the  required  calls  to  fork,  wait,  and  exit  respectively.  At  the  beginning  of  each  statement, 

“forkstmts”  calls  the  function  ” prforks”.  The  function  ” printexit”  is  called  when  the  end  of 
a  statement  is  found.  The  function  ’’prwaits”  is  called  when  the  end  of  the  cobegin-coend 
block  is  found,  “forkstmts”  first  initializes  the  stack  by  placing  a  semicolon  on  its  top. 

It  is  initially  assumed  that  the  end  of  each  statement  will  be  a  semicolon.  The  logic  of 
separating  the  C  statements  is  as  follows: 

1.  Whenever  a  symbol  is  found  -which  matches  the  top  of  the  stack,  pop  the  stack.  The  only 
symbols  which  are  screened  by  “forkstmts”  are  quotes,  semicolons,  left  parenthesis,  right 
parenthesis,  {,  and  }. 

2.  Between  each  statement,  “forkstmts”  will  search  for  the  keyword  “coend”.  This  marks  the  1 

end  of  the  cobegin-coend  block  and  “forkstmts”  will  return.  If  the  keyword  “cobegin”  is 

found  an  error  is  printed  and  “forkstmts”  will  return  with  an  error.  A  new  cobegin-coend 
block  as  a  statement  within  a  cobegin-coend  block  has  no  meaning. 

3.  Newline  characters  are  always  recognized.  The  precompiler  reads  the  old  source  file  one 
line  at  a  time.  The  current  line  is  printed  to  the  new  source  file  and  a  new  line  is  read 

from  the  old  source  file  on  each  newline  character.  . 

i 

4.  If  the  quote  symbol  is  found  within  a  statement,  ignore  every  syml  ol  except  newline  . 

characters  until  another  quote  symbol  is  found.  } 

5.  If  a  semicolon  symbol  is  found  and  the  top  of  the  stack  is  a  semicolon,  then  pop  the  stack.  ! 

» 

< 

J 
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If  the  stack  is  empty,  the  end  of  the  statement  has  been  found. 

6.  If  a  left  parenthesis  symbol  is  found  and  the  top  of  the  stack  is  either  a  right  parenthesis 
or  a  semicolon,  push  a  right  parenthesis  symbol  on  the  stack. 

7.  If  a  right  parenthesis  symbol  is  found  and  the  top  of  the  stack  is  a  right  parenthesis,  pop 
the  stack. 

8.  If  a  do  while  loop  is  found  at  the  beginning  of  a  statement,  turn  on  the  flag  “dostmt”.  The 
reason  for  this  flag  will  become  apparent  shortly. 

9.  If  a  {  symbol  is  found  and  the  top  of  the  stack  is  a  semicolon  and  dostmt  is  FALSE,  pop 
the  stack  and  push  a  }  symbol  on  the  stack.  In  the  case  of  dostmt  being  TRUE,  do  not  pop 
the  stack  and  just  push  on  the  symbol  }.  The  reason  for  this  is  that  a  do  while  statement 
ends  in  a  semicolon  symbol,  but  contains  a  {  }  block.  If  a  {  is  found  and  the  top  of  the 
stack  is  a  },  push  a  }  symbol  on  the  stack. 

10.  If  a  }  symbol  is  found  and  the  top  of  the  stack  is  a  },  pop  the  stack  and  check  for  empty 
stack.  If  the  stack  is  empty,  the  end  of  the  statement  has  been  found. 

11.  If  the  keyword  “cobegin”  is  found  within  a  statement,  then  push  the  symbol  k.  on  the  stack 
and  call  “forkstmts”  recursively.  The  &  symbol  is  called  a  stack  separator  and  is  used  to 
designate  the  empty  stack.  The  stack  separator  is  used  to  separate  different  segments  of  the 
stack  which  reflect  different  cobegin-coend  blocks.  This  allows  programmers  to  correctly 
nest  cobegin-coend  blocks. 

An  important  aspect  of  the  precompiler  is  that  it  expects  to  receive  a  syntactically  correct 
C  program.  If  the  syntax  of  the  C  source  file  is  incorrect,  the  results  of  the  precompiler  can 
not  be  predicted.  Any  programmer  using  the  precompiler,  should  first  comment  out  the 
keywords  “cobegin”  and  “coend”  and  try  to  compile  the  source  code.  This  will  inform  the 
programmer  if  his  source  code  is  syntactically  correct.  The  precompiler  also  attempts  to 
produce  structured  code.  When  the  precompiler  finds  a  cobegin-coend  block,  it  remembers 
the  column  number  where  the  keyword  “cobegin”  was  found.  All  inserted  code  is  then 
blocked  relative  to  this  column  number.  Thus,  if  the  precompiler  receives  a  structured 
program,  it  will  produce  a  structured  program.  Also  remember  that  the  variable  names  ii, 
jj,  pid,  and  pidarray  are  reserved  when  using  the  precompiler.  If  these  names  are  used  in 
the  program,  problems  could  occur. 


4.2  Examples  of  Cobegin-Coend 


This  section  presents  a  number  of  examples  which  will  aid  the  reader  in  understanding 
the  functionality  of  the  cobegin-coend  construct.  Each  example  is  very  simple.  The  first 
four  examples  illustrate  the  implementation  of  the  precompiler.  Each  of  these  examples 
presents  the  new  source  code  after  precompilation.  These  examples  are  also  void  of  any 
synchronization  between  child  processes.  Again  these  examples  are  meant  to  show  the 
functionality  of  the  cobegin-coend  not  synchronization  primitives.  The  last  examples 
present  some  of  the  classic  problems  of  concurrent  environments  written  in  C  using  the 
cobegin-coend  construct. 

4.2.1  Function  Calls 

Example  24a  is  composed  of  two  routines  which  share  an  array  of  counters.  The  main 
routine  wishes  to  increment  each  counter  by  ten,  concurrently.  The  main  routine  first 
initializes  each  counter  and  then  calls  the  function  “add”  for  each  counter.  The  function 
“add”  accepts  an  index  into  the  array  of  shared  counters  and  the  value  to  add  to  a  counter. 
The  main  routine  calls  “add”  within  a  cobegin-coend  block.  This  ensures  that  every  call 
to  “add”  is  made  concurrently.  Example  24b  shows  the  changes  made  to  the  source  code 
by  the  precompiler.  The  syntax  and  semantics  of  the  code  are  as  described  in  section  4.1. 
Notice  that  the  array  “pidarrav”  and  the  integers  ii,  jj,  and  pid  are  placed  before  the  main 
routine.  The  array  size  is  set  to  25  because  that  is  the  maximum  number  of  processes  any 
one  user  can  create  on  the  current  system  at  one  time.  This  value  can  easily  be  changed 
in  the  precompiler  function  “find-block”.  Also  notice  that  the  appearance  of  the  inserted 
code  is  in  a  structured  format.  In  this  example,  it  would  have  been  just  as  easy  to  perform 
the  two  statements  of  the  “add”  function  in  a  block  of  code  within  the  cobegin-coend 
block.  However,  these  examples  are  not  presenting  realistic  situations,  but  are  only  meant 
to  show  functionality. 


. . 

/•  Example  24a  •/ 

/ . / 

^include  <  s  t  d i o . h> 

/»  This  program  increments  an  array  of  counters.  The  function  •/ 
/»  "add"  receives  an  index  into  the  array  of  counters  and  the  •/ 
/«  amount  to  add  to  that  counter.  The  mo i n  routine  •/ 

/«  initializes  each  counter  to  zerc  and  then  adds  10  to  each  *  / 
/•  counter  concurrently  using  a  cobegin  -  coend  block.  •/ 


/•  array  of  counters  •/ 


shored  int  count [5]  ; 

add  (  i  ,  n ) 
int  i  ,  n ; 

i 


count [ i ]  =  count[i]  +  n; 

printf  ("Counter  % d  is  now  %d\n".  i,  count [ i ] ) ; 


main  (  ) 

\ 

int  i  ; 

for  ( i  =  0;  i<5,  i++) 

count [ i ]  =  0; 

setbuf  (stdout.  NULL);  /•  no  output  buffer  •/ 
/*  add  10  to  each  counter  concurrently  »/ 


C  o  be  g  i  n 

add  (0.  10) 

add  ( 1 ,  10) 

add  (2,  10) 

add  ( 3 .  10) 

add  ( 4  ,  10) 

coend 


printf  ("Everyone  is  done\n" ) ; 


/«  Example  24b  •/ 

/ . / 


^include  <stdio.h> 

/•  This  program  increments  an  array  of  counters.  The  function  */ 
/•  "add"  receives  an  index  into  the  array  of  counters  and  the  •/ 
/»  amount  to  add  to  that  counter.  The  main  routine  »/ 

/*  initializes  each  counter  to  zero  and  then  adds  10  to  each  •/ 
/•  counter  concurrently  using  a  cobegin  -  coend  block.  •/ 

shared  int  count [5] ;  /•  array  of  counters  •/ 

add  (  i  ,  n ) 
int  i  ,  n  ; 

) 


count [ i ]  =  count [ i ]  +  n; 

printf  ("Counter  Zd  is  now  55d  \  n "  ,  i,  count  [  i  )  )  ; 


int  pidarray[25]; 
int  status,  pid.  ii; 
static  int  jj  =  jlj, 
main  (  ) 

\ 

int  i  ; 


for  (i  =  0;  i  <  5;  i++) 

count [ i ]  =  0; 

setbuf  (stdout,  NULL);  /•  no  output  buffer  •/ 
/•  add  10  to  each  counter  concurrently  • / 


p  i  d 
i  f 

i  f 


p  i  d 
i  f 

i  f 


p  i  d 
i  f 

i  f 


p  i  d 
i  f 

i  f 


P  '  d 

i  f 

i  f 


for 


=  fork  ( ) ; 

(pid  ! =  0 ) 

pidarray[jj++]  =  pid; 
( p i d  ==  0 )  ) 

add  ( 0 ,  16); 

exit  (0)  .  ( 

=  fork  ( ) ; 

(pid  ! =  0 ) 

p i da  r  roy [  j  j++ ]  =  pid; 

(pid  ==  0 )  j 
add  ( 1 ,  10). 

exit  ( 0 ) ;  j 
=  fork  (  )  ; 

(pid  ! =  0  ) 

pidarroy[j|++]  =  pid; 
(pid  ==  0 )  1 

add  ( 2 .  10); 

exit  ( 0 ) ,  i 
=  fork  ( ) . 

(pid  1 =  0 ) 

pidarray[|j++]  =  pid 
(pid  ==  0  I  j 

add  ( 3 .  1C,, 

exit  (  0 /  .  ( 

=  fork  (  1.  , 
i  P  |  d  '  =  0  i 

P'dorroy[j)  +  -t]  =  pid. 

(  P  ■  d  =  =  0  )  i 

add  ( 4 ,  10), 

ext  ( 0 ) .  ( 


(ii  =0.  ii  <5.  .  iff) 

P'd  =  wait  (  Ir  s  (  a  t  us  )  . 


I 


4.2.2  Blocks  of  Code 

Example  25a  shows  the  exact  same  program  shown  in  example  24a.  However,  counter  2  will 
be  incremented  three  times  and  counter  3  will  incremented  twice.  Again  the  function  “add” 
accepts  the  index  of  the  counter  and  the  value  to  add  to  the  counter.  Notice  that  the  block 
symbols  {  and  }  are  placed  around  all  the  calls  to  “add”  for  counter  2  and  counter  3.  These 
two  blocks  of  code  will  be  executed  concurrently  with  every  other  statement  in  the  cobegin- 
coend  block.  However,  each  call  within  these  two  blocks  are  executed  sequentially.  In  this 
example,  no  synchronization  mechanisms  are  needed  for  mutual  exclusion  since  multiple 
adds  on  a  specific  counter  are  executed  sequentially.  The  blocking  of  code  is  important  to 
the  cobegin-coend  construct  because  it  allows  the  declaration  of  local  variables  and  allows 
the  programmer  the  ability  to  perform  some  sequential  execution  within  the  cobegin-coend 
block.  Of  course  calling  a  function  within  the  cobegin-coend  block  has  the  same  result, 
but  with  the  overhead  of  a  function  call.  Example  25b  shows  the  precompiler  output 
for  example  25a.  Notice  that  for  each  block  statement,  the  precompiler  still  generated 
enclosing  brackets  for  the  child  process.  Both  pairs  of  {  }  are  not  needed.  Both  pairs  of 
brackets  were  retained  for  simplicity  to  the  precompiler. 


i 


i 

t 


/•  Ex  amp  I e  25a  */ 

/••••• . * . / 


finclude  <stdio.h> 

/•  This  program  increments  an  array  of  counters.  The 
/•  "add"  receives  an  index  into  the  array  of  counters 
/•  amount  to  add  to  that  counter.  The  main  routine 
/•  initializes  each  counter  to  zero  and  then  adds  10  t 
/•  counters  0.  1,  and  4  .  The  main  routine  adds  30  to 

/•  2  in  increments  of  10  and  adds  20  to  counter  3  in 

/•  increments  of  10.  Counters  2  and  3  are  incremented 

/•  sequentially  by  using  the  symbols  j  and  j  to  block 
/ •  code. 

shared  int  count [5]  ;  /•  array  of  counters  •/ 

odd  ( i ,  n ) 
int  i  ,  n  ; 

i 


count]  i  ]  =  count [  i  ]  +  n  ; 

printf  ("Counter  %d  is  now  %d\n",  i,  count [  i  ])  ; 


main  (  ) 

i 

int  i  ; 

for  ( i  =  0  ;  i  <  5 ;  i ++ ) 
count [ i ]  =  0 ; 

setbuf  (stdout.  NULL);  /•  no  output  buffer  •/ 

/•  Increment  each  buffer  concurrently  •/ 

c  o  b  e  g  i  n 

add  (0 ,  10); 

add  ( 1 ,  10) ; 

]  add  ( 2 ,  10); 

odd  (2 ,  10) ; 

add  ( 2 ,  10).  | 

1  add  ( 3 .  10); 

add  ( 3 ,  10);  ( 

add  (4 ,  10)  ; 

c  o  e  n  d 


f  u  n  c  t  ion 
and  the 

o 

counter 

the 


printf  ("Everyone  is  done\n"  )  ; 


/ •  E  *  am  p I e  2  5b  *  / 

/ . * . / 

(((include  <  s  t  d  i  o  .  h  > 

/•  This  program  increments  an  array  of  counters.  The  function 
/»  "add"  receives  an  index  into  the  array  of  counters  and  the 
/*  amount  to  add  to  that  counter.  The  main  routine 
/»  initializes  each  counter  to  zero  and  then  adds  10  to 
/»  counters  0,  1.  and  4.  The  main  routine  adds  30  to  counter 

/•  2  in  increments  of  10  and  adds  20  to  counter  3  in 

/  *  increments  of  10.  Counters  2  and  3  are  incremented 

/•  sequentially  by  using  the  symbols  J  and  j  to  block  the 
/•  code  . 

shared  int  count [5]  ;  /•  array  of  counters  »/ 

add  ( i ,  n ) 
int  i ,  n ; 

I 

count [ i ]  =  count [ i ]  +  n; 

printf  ("Counter  %d  is  now  %d\n",  i.  count [ i  ])  ; 

I 

int  pidarray[25]; 
int  status,  pid.  i  i  ; 
static  int  j  j  =  J 1  j  ; 
main  (  ) 

1 

int  i  ; 

for  (i  =0;  i  <  5;  i ++ ) 
countfi]  =  0; 

setbuf  (stdout,  NULL);  /•  no  output  buffer  •/ 

/•  Increment  each  buffer  concurrently  •/ 

pid  =  fork  (  )  ; 
if  (pid  ! =  0 ) 

pidarray[jj++]  =  pid; 
if  ( p i d  ==  0 )  j 
add  (0 .  10); 

exit  ( 0  )  ,  ! 

pid  =  fork  (  )  ; 
if  (pid  !  =  0 ) 

pidorray[jj++]  =  pid; 
if  (pid  ==  0 )  J 
add  ( 1 ,  10). 

exit  ( 0 ) .  ( 

pid  =  fork  ( ) ; 
if  (pid  1 =  0 ) 

pidarray[jj++]  =  pid, 
if  (  p  i  d  ==  0  )  i 

)  odd  ( 2 ,  10). 

odd  (  2  .  10,'. 

odd  (2 .  10/.  | 

exit  (0)  .  j 

pid  =  fork  (  )  . 
if  (pid  '  =  0  ) 

p  i  dor  roy [  |  |+*  ]  =  pid. 

if  (pid  =  =  0 )  ) 

)  odd  ( 3 .  10); 

add  ( 3 .  10).  | 

exit  ( 0 ) .  | 


p  i  d 

fork  (  )  ; 

i  f 

(  P  ' 

d  !=  0) 

pidarray[jj++]  = 

p  i  d  ; 

i  f 

(  P  i 

d  ==  0) 

i 

add 

(4,  10) 

; 

e  x  i 

t  (0) ; 

i 

for 

(  i 

i  =  0;  i 

i  <  5  ; 

i  >++)  i 

p  i  d 

-  wo  i  t 

(tstat 

us); 

i  f 

(status) 

1 

j  j  =  0  ; 

while  ( p 

id  !  = 

pidarray[jj]) 

j  j++i 

t 

f 

p  r  i  n  t  f  ( 

"Error 

on  Stmt  %d  in  cobegin  block\n 

pr  i 

n  t  f 

(“Everyone  is 

done\n") ; 
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4.2.3  Block  Statements 

Example  26a  is  a  mild  change  to  example  24a.  In  this  example,  each  counter  is  incremented 
ten  times  by  calling  “add”  ten  times.  Each  time  the  function  “add”  increments  the  counter 
bv  ten.  In  the  cobegin-coend  block  a  for  loop  is  placed  around  each  call  to  “add”.  This 
does  not  mean  that  50  processes  are  created,  but  that  five  processes  are  created,  each  of 
which  executes  one  of  the  for  loops.  Again,  this  example  certainly  is  not  the  most  effective 
method  for  incrementing  these  loops.  It  would  be  best  to  bypass  the  ten  function  calls  for 
each  process.  Example  26b  contains  the  precompiler  output  for  example  26a.  Notice  that 
each  entire  for  loop  is  contained  in  a  block  of  code  to  be  executed  by  a  child  process.  The 
for  loops  could  have  been  different  sizes. 


/ . / 

/»  Example  26a  */ 

/ . / 


ifincljde  < s  t  d i o . h> 

/•  This  program  increments  an  array  of  counters.  The  function  */ 


/*  "add"  receives  an  index  into  the  array  of  counters  and  the  •/ 
/•  amount  to  add  to  that  counter.  The  main  routine  */ 
/  *  initializes  each  counter  to  zero  and  then  adds  100  to  each  »/ 
/•  counter  concurrently  using  a  cobegin  -  coend  block.  *  / 
/•  Each  counter  is  incremented  to  100  by  10s.  •/ 


shared  int  count [5] ;  /•  array  of  counters  */ 

add  ( i ,  n ) 
int  i  ,  n ; 

countfij  =  count [ i ]  +  n; 

printf  ("Counter  %d  is  now  %d\n",  i,  count [  i  ]  )  ; 

\ 

main  (  ) 

j 

int  i  ; 

for  (i  =0;  i  <5;  i++) 

c  oun  t [  i  ]  =  0 ; 

setbuf  (stdout,  NULL);  /•  no  output  buffer  •/ 
/•  add  100  to  each  counter  concurrently  »/ 
c  o  b  e  g  i  n 


for  (  i 

=  0 

i  < 

1 0 , 

'•++) 

odd 

(0 

10)  ; 

for  (  i 

=  0 

i  < 

10; 

i++) 

odd 

(  1 

10); 

for  (  i 

=  0 

i  < 

1  0  ; 

'++) 

add 

(2. 

10)  ; 

for  (  i 

=  0 

i  < 

1  0  ; 

i++) 

add 

(3  . 

10); 

for  (  i 

=  0 

< 

1  0  . 

'+  +  ) 

odd 

(  4  ■ 

10), 

c  o  e  n  d 


f 


printf  ("Everyone  is  done\n") ; 


/ . / 

/»  £  x  omp  I  e  26b  •/ 

/ . / 


| i nc I ude  <  s  t  d  i  o  h  > 

/•  This  program  increments  an  array  of  counters.  The  function  */ 


/•  "add"  receives  an  index  into  the  array  of  counters  and  the  •/ 
/•  amount  to  odd  to  that  counter.  The  main  routine  •/ 
/•  initializes  each  counter  to  zero  and  then  adds  100  to  each  *  / 
/•  counter  concurrently  using  a  cobegin  -  coend  block.  «/ 
/•  Each  counter  is  incremented  to  100  by  10s.  •/ 


shored  int  count[5];  /•  array  of  counters  •/ 

odd  ( i ,  n ) 

int  i ,  n ; 

5 

count[i]  =  count  [  i  ]  +  n; 

printf  ("Counter  %d  is  now  5£d\n",  i,  count  [  i  ])  ; 


int  pidarroy[25]; 
int  status,  pid.  ii; 
static  int  jj  =  )1j; 

main  (  ) 

) 

int  i  ; 

for  (i  =0;  i  <5;  i++) 

count [ i ]  =  0; 

setbuf  (stdout,  NULL);  /•  no  output  buffer  •/ 

/•  odd  100  to  each  counter  concurrently  •/ 


pid  =  fork  (); 
if  (pid  ! =  0 ) 

pidorray(jj+-*-]  = 
if  (  p  i  d  =  =  0  )  j 
for  ( i  =  0 .  i  < 
ada  ( 0 ,  10). 

exit  ( 0  )  .  t 
pid  =  fork  (  )  , 
if  (pid  ! =  0 ) 

pidarray[jj++]  = 
if  (pid  ==  0 )  j 
for  ( i  =  0 ;  i  < 
odd  ( 1  ,  10)  ; 

exit  ( 0  )  ,  j 
pid  =  fork  (  )  ; 

.f  (pid  1  =  0  ) 

pidarray[jj++]  = 
if  ( p i d  ==  0 )  ) 

for  (  i  =  0  ,  i  < 
odd  ( 2 .  10). 

exit  f  0 )  ;  ( 

p.d  =  fork  (  )  : 

■  f  (p.d  1 =  0  ) 

pido'roy[jj++l  = 
i '  Ip ■ d  ==  0 /  j 

for  f  i  =  0 ,  i  < 

odd  ( 3  .  1 0  I  . 

exit  (0)  ,  ( 

pid  =  fork  (  )  . 
i  *  I  p  i  d  1  =  0  1 

pidarroy[jj++]  = 


pid; 

10,  i++) 

pid; 

10.  i ++ ) 

pid; 

10,  i ++  ) 

pid. 

10  l  4  +  ) 

pid. 


4.2.4  Nesting  Cobegin  Blocks 


Example  27a  illustrates  the  programmer’s  capability  to  nest  cobegin-coend  blocks.  In  this 
example,  each  of  the  five  counters  are  to  be  incremented  by  different  values.  Counters  0, 
1,  and  2  are  to  incremented  until  their  combined  values  exceeds  110.  Counters  3  and  4 
are  to  be  incremented  until  their  combined  values  exceed  75.  Notice  that  two  independent 
while  loops  are  used  to  test  and  increment  the  two  sets  of  counters.  These  two  loops 
are  independent  and  can  execute  concurrently.  Thus,  they  are  placed  within  a  cobegin- 
coend  block.  Also  notice  that  each  call  to  “add”  is  independent  and  can  be  executed 
concurrently  with  every  other  add  operation.  Thus,  each  call  to  “add”  within  each  while 
loop  is  also  placed  within  a  cobegin-coend  block.  Each  cobegin-coend  block  within  a  while 
loop  provides  the  synchronization  needed  by  the  loop  to  check  the  totals  of  each  counter 
set.  Example  27b  contains  the  source  code  produced  by  the  precompiler  for  example  27a. 
The  first  child  process  executes  the  while  loop  containing  counters  0,  1,  and  2.  Also,  three 
child  processes  are  created  within  the  while  loop,  one  for  each  counter.  Notice  that  a 
structured  appearance  is  maintained. 
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if  ( p i d  ==  0 )  ) 

for  (i  =  0;  i  <  10;  i++) 

odd  ( 4 ,  10); 

exit  ( 0 ) ;  I 

for  (ii  =0;  ii  <5;  ii ++ )  ) 

pid  =  wait  (tstotus) ; 
if  (status)  | 
j  j  =  0  ; 

while  (pid  !=  p i da r r ay [ j j ] ) 
j  j  ++  ; 

printf  ("Error  on  Stmt  %d  in  cobegin  block\n",jj) 

i 


irintf  ("Everyone  is  done\n") 


/ . / 

/•  Example  27a  •  / 

/ . / 


# i n c  I  u d e  <  s  t  d i o . h> 

/  ♦  This  program  increments  an  array  of  counters.  The  function  •/ 
/♦  "add"  receives  an  index  into  the  array  of  counters  and  the  •/ 
/•  amount  to  add  to  the  counter.  The  main  routine  increments  •  / 
/  ♦  counters  0.  1,  and  2  until  their  values  add  up  to  more  than  ♦  / 

/  ♦  110.  It  increments  counters  3  and  4  until  their  volues  add  ♦  / 

/♦  up  to  more  than  75.  Each  addition  of  a  counter  is  done  ♦  / 

/  ♦  concurrently.  This  program  illustrates  nesting  of  cobegin  ♦/ 
/♦blocks.  •/ 

shared  int  count [5] ;  /♦  array  of  counters  •/ 

add  ( i ,  n ) 
int  i  ,  n ; 

I 

count [  i  ]  =  count(  i  ]  +  n  ; 

printf  ("Counter  %  d  is  now  %d\n",  i.  count [  i  ]  )  ; 

i 

ma in  (  ) 

I 

int  i  ; 

for  (i  =  0;  i  <5;  i  ++ ) 
count [ i ]  =  0 ; 

setbuf  (stdout.  NULL);  /•  no  output  buffer  •/ 

/♦  Increment  counters  concurrently  ♦/ 
c  o  be  g  i  n 

while  (count [8]  +  count  [  1  ]  +  count[2]  <  110)  S 
c  o  b  e  g  i  n 

odd  ( 0  ,  7  )  ; 

add  ( 1 .  10); 

add  (2 .  15); 

c  o  e  n  d 

* 

while  (count [3]  +  count[4]  <  75)  j 
c  o  be  g  i  n 

add  ( 3 ,  10); 

add  ( 4 ,  10); 

coend 

I 

c  o  e  n  d 


printf  ("Counters  0,1.  and  2  added  equal  %d\n",  count[0]+count[l]+count[2]) 
printf  ("Counter  3  ond  4  added  equal  %d\n",  cour t [3]+count [ 4] ) ; 


/•  Example  27b  •/ 
/ . / 


^include  <stdio.h> 

/*  This  program  increments  on  array  of  counters.  The  function 
/»  "add"  receives  an  index  into  the  array  of  counters  and  the 
/•  amount  to  add  to  the  counter.  The  main  routine  increments 
/•  counters  0,  1.  and  2  until  their  values  add  up  to  more  than 

/•  110.  It  increments  counters  3  and  4  until  their  values  add 
/*  up  to  more  than  75,  Each  addition  of  a  counter  is  done 
/ *  concurrently.  This  program  illustrates  nesting  of  cobegin 
/ •  blocks. 


shared  int  count [5)  ; 

add  (  i  ,  n  ) 
int  i  ,  n ; 

1 


count [ i ]  =  count [ i ]  +  n; 

printf  ("Counter  % d  is  now  %d\n", 


array  of  counters 


i,  count [ i ] ) 


int  pidarray[25]; 
int  status,  pid,  ii; 
static  int  j  j  =  j  1  |  ; 
main  (  ) 

I 

int  i  ; 

for  (i  =0;  i  <5;  i++) 

c  o  u  n  t  [  i  ]  =  0  ; 

setbuf  (stdout,  NULL);  /•  no  output  buffer  •/ 

/•  Increment  counters  concurrently  */ 

pid  =  fork  (  )  ; 

if  (pid  ! =  0 ) 

pidarray[jj++]  =  pid; 

if  (pid  ==  0 )  j 

while  (count [0]  +  count [  1  ]  +  count[2]  <  110)  j 
pid  =  fork  (  )  ; 
if  (pid  ! =  0 ) 

pidarray[jj++]  =  pid; 
if  (pid  ==  0 )  j 
add  ( 0 ,  7 )  , 

exit  ( 0  )  ;  j 
pid  =  fork  ( ) , 
if  (pid  ! =  0 ) 

pidarray[jj++]  =  pid; 

if  ( p i d  ==  0 )  | 

add  ( 1 ,  10); 

exit  ( 0 )  ;  ( 

pid  =  fork  ( ) ; 

if  (pid  1=0) 

p i do  r  r ay (  j  j++ ]  =  p'd, 
if  ( p i d  ==  0 )  ) 

odd  ( 2  .  15), 

exit  ( 0  )  ,  ! 

for  (  i  i  =  0,  ii  <  3;  i  i +  + )  ) 

pid  =  wait  ((status), 
if  (status)  j 
j  f  =  ®. 

while  (pid  1 =  p i da  r  ray [  j  j  )  ) 

J  )++  ■ 


.4' 


it. 


printf  ("Error  on  Stmt  Zd  in  cobegin  b  I  o  c  k  \  n  "  .  j  j  )  ; 


exit  ( 0 )  ;  ( 

o  i  d  =  fork  (  )  ; 
if  (  p  i  d  !  =  0  ) 

pidarray[jj++]  =  pid; 
i  f  ( p i d  ==  0 )  ) 

while  (count [3]  +  count[4]  <  75)  J 
pid  =  fork  (  )  ; 
if  (pid  ! =  0 ) 

pidarray[jj++]  =  pid; 
if  (  p ( d  ==  0 )  j 
add  ( 3 ,  10); 

exit  ( 0 ) ;  j 
pid  =  fork  ( )  ; 
if  (pid  ! =  0 ) 

pidarray[jj++]  =  pid; 
if  ( p i d  ==  0  )  ) 

odd  ( 4  ,  10); 


exit  ( 0  )  ;  j 

for  ( i i  =  0 ;  i i  <  2  ;  i i ++ )  j 
pid  =  wait  (tstatus); 
if  (status)  ) 
i  j  =  0  ; 

while  (pid  .'=  pidarroyfjj]) 
j  j  ++  ; 

printf  ("Error  on  Stmt  %d  in  cobegin  b I oc k\n " , j j ) ; 

I 


exit  (0)  ;  ( 

for  (ii  =0;  ii  <2;  ii  ++ )  j 
pid  =  wait  (tstatus); 
if  (status)  ) 
j  j  =  0  . 

while  (pid  !=  pidorray[jj]) 
j  j  ++  ; 

printf  ("Error  on  Stmt  %d  in  cobegin  block\n",jj); 


printf  ("Counters  0,1,  and  2  added  equal  %d\n",  c o u n t [ 0 ]  +  c o u n t [ 1  ]  +  c o u n t [ 2 ] ) 
printf  ("Counter  3  and  4  odded  equal  %d\n",  count [3]  +  counl  [4]  )  ; 


4.2.5  Dining  Philosophers 


! 

Example  28  is  a  solution  to  the  Dining  Philosophers  problem.  In  this  problem,  there  are 
five  philosophers.  Each  philosopher  spends  his  day  in  two  activities,  eating  and  thinking. 
After  spending  a  certain  amount  of  time  thinking,  a  philosopher  will  become  hungry  and 
want  to  eat.  In  this  solution,  a  philosopher  must  enter  the  dining  room  to  eat.  Only  four 
philosophers  are  allowed  in  the  dining  room  at  a  time.  This  restriction  ensures  the  absence 
of  deadlock.  The  dining  room  contains  a  large  round  table  with  five  place  settings,  one  for 
each  philosopher.  In  the  center  of  the  table  is  a  large  bowd  of  spaghetti.  There  are  a  total 
of  five  forks  on  the  table,  one  between  each  place  setting.  After  a  philosopher  has  entered 
the  dining  room,  he  must  first  pick  up  the  fork  on  his  left  and  then  pick  up  the  fork  on  his 
right  in  order  to  eat  the  spaghetti. 

This  example  combines  the  s  Jock  routines  provided  by  DYNIX  and  the  cobegin-coend 
construct  provided  by  the  precompiler.  There  are  six  locks.  An  array  of  five  locks  is 
declared  to  represent  each  of  the  five  forks.  Thus,  when  a  philosopher  attempts  to  pick  up 
a  fork  which  is  being  used  (locked),  he  must  wait.  If  a  philosopher  picks  up  his  left  fork  and 
the  right  fork  is  being  used,  he  will  not  put  down  the  left  fork.  The  lock  “room”  is  used  to 
monitor  the  amount  of  philosophers  in  the  dining  room.  The  variable  “occupy”  holds  the 
number  of  philosophers  in  the  dining  room.  To  enter  the  dining  room,  a  philosopher  will 
first  obtain  the  lock  “room”  and  then  check  the  variable  “occupy”.  If  “occupy”  is  less  than 
four,  the  philosopher  increments  “occupy”,  releases  the  lock,  and  enters  the  dining  room. 
If  “occupy”  is  equal  to  four,  he  releases  the  lock  and  tries  again.  The  main  routine  creates 
five  philosophers  using  a  cobegin-coend  block.  Each  philosopher  receives  his  philosopher 
number,  the  index  into  “forks”  for  his  left  fork,  and  the  index  to  his  right  fork.  Notice 
how  easy  it  was  to  place  each  philosopher  into  execution  on  a  separate  process  by  using 
the  cobegin-coend  construct.  Also,  notice  how  clearly  the  cobegin-coend  block  defines  the 
concurrent  tasks. 


/*•♦ . 

/•  Example  28 

/ . 


/ 

/ 

/ 


#  include  <poral  le l/mi crotask . h> 

^include  <pora I  I  e  l/pora I  I e I  . h> 

§  i  nc  I  ude  <s  t  d i o . h> 

^define  TRUE  1 
{^define  FALSE  0 

/•  This  program  is  a  solution  to  the  Dining  Philosophers  problem.  • 

/•  In  this  problem,  there  are  five  philosophers.  Each  philosopher  • 

/•  does  two  things,  he  eats  and  thinks.  In  order  to  eat,  a  » 

/•  philosopher  must  enter  the  dining  room,  pick  up  his  right  fork  • 

/•  and  pick  up  his  left  fork.  The  problem  is  that  there  ore  only  • 

/*  five  forks,  one  between  each  of  five  place  settings.  In  this  » 

/•  solution,  the  dining  room  acts  as  a  lock  and  allows  only  four  • 

/•  philosopher  to  enter.  Each  fork  is  also  a  lock.  If  o  • 

/•  philosopher  attempts  to  pick  up  o  fork  and  finds  that  it  is  • 

/•  already  in  use.  the  philosopher  will  wait  for  the  fork  to  be  • 

/•  ploced  back  on  the  table.  After  a  philosopher  has  eaten,  he  • 

/»  will  put  down  both  forks  and  leave  the  dining  room  to  continue  • 

/•  thinking.  The  forks  are  declared  os  on  array  of  locks.  The  • 

/•  philosophers  receive  indices  into  the  array  which  designate  • 

/•  both  their  left  and  right  forks.  • 

shared  slock_t  f orks[5] ,  room; 
shared  int  occupy; 

think  (philnum) 
int  philnum; 

1 

printf  ("Philosopher  % d  is  ThinkingNn",  philnum); 

i 

eat  (philnum) 

int  philnum; 

i 

printf  ("Philosopher  55 d  is  Eating\n",  philnum); 

i 

pickupfork  (forknum) 
int  forknum; 

i 

s_lock  ( k I o r k s [ f o r k n urn ] ) ; 

I 

putdownfork  (forknum) 
int  forknum; 

i 

s.unlock  (  &  f  o  r  k  s  [  f  o  r  k  n  urn  ]  )  ; 

! 

enterroom  (philnum) 
int  philnum; 

I 

int  in, 
in  =  FALSE . 

while  (I  in)  | 

s_lock  (iroom), 

if  (occupy  <  4  J  |  /  •  Is  there  room  for  me  to  enter  *  / 

oc  c  u  py  +  + ; 
in  =  TRUE; 

printf  ("Philosopher  55  d  has  Entered  Dining  Room\n",  philnum), 

i 

s_unlock  (iroom) ; 


i$ 

£ 


Sffixr  w&x&r 


I 


i 

exit  room  (philnum) 
i n  t  philnum; 

I 

s_ I oc  k  (icroom); 
occupy — ; 

printf  ("Philosopher  %d  hos  left  the  Dining  Room\n",  philnum) 
s_un I ock  (troom) ; 

I 


phil  (philnum,  left,  right) 

int  philnum,  left,  right; 

1 

int  days; 

for  (days  =  0;  days  <  5;  days++)  j 
think  (philnum); 
enterroom  (philnum); 
pickupfork  (left); 
pickupfork  (right); 
eat  (philnum); 
putdownfork  (left); 
putdownf ork  (right); 
ex i  t  room  (philnum); 

I 

j 

main  (  ) 

! 

int  i  ; 

for  (i  =0;  i  <5;  i++)  /♦  creat  locks  •/ 

s_ i n i t_ I ock  (if orks( i ] ) ; 

s_init_lock  (troom) ; 

/♦  Begin  each  Philosopher  •/ 


c  o  b  e  g 

n 

ph 

1 

(0. 

4  , 

0) 

ph 

1 

(1  . 

0  . 

1) 

ph 

1 

(2, 

1  , 

2) 

ph 

1 

(3. 

2  . 

3) 

ph 

coend 

1 

(4  . 

3  , 

4) 

I 


4.2.6  Bounded  Buffer 


Example  29  shows  a  solution  to  the  Bounded  Buffer  problem.  In  this  problem,  there  are 
two  producers  and  two  consumers.  Each  producer  wishes  to  write  to  an  array  of  buffers 
and  each  consumer  wishes  to  read  from  the  array  of  buffers.  The  problem  is  that  the 
array  of  buffers  is  limited  in  size.  So,  if  the  producers  write  faster  than  the  consumers 
read,  they  will  overwrite  their  data.  If  the  consumers  read  faster  than  the  producers 
write,  they  will  read  either  old  data  or  nonexistent  data.  This  is  a  basic  synchronization 
problem.  In  this  example,  the  array  can  hold  up  to  10  buffers.  Each  producer  will  write 
10  messages  to  the  array  of  buffers  for  a  total  of  20  messages.  Each  consumer  will  read  10 
messages.  Each  buffer  will  hold  two  items,  the  producer  number  and  a  message  number. 
The  lock  “prods Jk”  is  used  to  ensure  that  each  producer  does  not  attempt  to  write  to  the 
same  buffer.  The  lock  “consjk”  is  used  to  ensure  that  each  consumer  does  not  attempt 
to  read  from  the  same  buffer.  These  two  locks  ensure  mutual  exclusion.  Another  type 
of  synchronization  problem  is  conditional  synchronization.  In  this  example,  the  variable 
“empty”  holds  the  number  of  empty  buffers.  Each  time  a  buffer  is  read  by  a  consumer, 
empty  is  incremented.  The  variable  “full”  is  used  to  hold  the  number  of  full  buffers.  Each 
time  a  producer  writes  to  a  buffer,  full  is  incremented.  A  producer  can  only  write  to  the 
array  of  buffers  if  empty  is  greater  than  zero  and  a  consumer  can  only  read  from  the  arrav  of 
buffers  if  full  is  greater  than  zero.  This  is  referred  to  as  conditional  synchronization.  The 
two  locks  “fullJk”  and  “empty  Jk”  are  used  to  ensure  mutual  exclusion  when  updating 
“full”  and  “empty”,  respectively.  Once  again  each  producer  and  consumer  was  created 
and  placed  in  execution  using  a  cobegin-coend  block.  This  example  demonstrates  the 
cobegin-coend  construct’s  capability  to  create  processes  which  execute  different  routines. 


f 


« ■  iViL 


/ . / 

/»  Example  29  •/ 

/ . / 


#  i  nc  I ude  <s  t  d i o . h> 

#include  < pa r a  I  I e I /m i c r o t a s k . h> 
find  ude  <poro  I  I e l/poro I  I e I  . h> 
fdefine  N  10 
fdefine  TRUE  1 
jfdefine  FALSE  0 


/«  This  program  illustrates  the  Bounded  Buffer  problem.  In  this  •/ 
/•  program,  there  ore  two  producers  and  two  consumers.  The  producers  •/ 
/  *  write  their  ID  and  a  message  number  to  a  shared  array  buffer.  The  •/ 
/•  consumers  read  the  buffer  and  print  a  message.  The  message  tells  •/ 
/•  the  message  number  and  the  producer  who  wrote  it  The  shared  •/ 
/»  buffer  can  hold  10  messages.  Each  producer  will  write  10  messages  »/ 
/•  for  a  total  of  20  messages.  There  are  four  locks  to  ensure  mutual  •/ 
/»  exclusion  when  reoding  and  writing  a  message  and  to  ensure  that  •/ 
/•  buffer  does  not  overflow  or  underflow  •/ 
/•  cons_lk  -  only  one  consumer  may  read  ot  a  time  »/ 
/»  prod_lk  -  only  one  producer  igov  »ritt  at  at  tine  •/ 
/»  empty_lk  -  mutual  exclusion  on  the  variable  empty  »/ 

/»  full _ Ik  —  mutuol  exclusion  on  the  variable  full  */ 

/»  The  variable  empty  tells  how  many  buffers  are  empty  and  is  »/ 
/»  initialized  to  10  The  variable  full  tells  how  many  messages  are  •/ 
/•  in  the  array  of  buffers.  Only  one  producer  may  write  to  o  buffer  »/ 
/  •  at  a  time  and  only  if  empty  is  greater  than  zero.  Only  one  •/ 
/•  consumer  may  read  from  a  buffer  at  a  time  and  only  if  full  is  */ 
/•  greater  than  zero  •/ 


shared  slock_t  prod_lk,  cons_lk,  f  u 1  1 _ J  k ,  empty_lk; 

struct  entry  ) 
i  n  t  p  r  n  urn  ; 
int  msgnum, 

I  ; 

shared  int  ir  out.  empty,  full; 

shared  struct  entry  buf  fer[N] ;  /«  array  of  buffers  •/ 

producer  (num) 
int  num, 

i 

int  i  ,  c  o  n  t  , 

for  (i  =0,  i  <N;  i++)  j 

cont  =  FALSE; 

while  (I  cont)  J  /  •  wait  until  there  is  an  empty  buffer  •/ 

s_lock  (  4emp  t  y_  I  k  )  ; 
if  (empty  >0)  ) 

cont  =  TRUE; 
empty  — ; 

I 

s_unlock  (  Jcemp  t  y  _  I  k  )  ; 

s  _  '  c  :  k  (  4  o  r  o  d  _  I  k  ;  ; 

bnfferfin]  msgnum  =  i  +  1 

buffer(in)  prnum  =  num. 
in  =  (in  t-  1  )  7,  N  , 
s_un!ock  (4prod_!k), 

s_lock  (4  f  u  I  I  _ I k )  , 

fuil+-t;  /•  Increment#  of  ful'  buffers  •/ 

s_unlock  ( 4  f  u I  I  _ I k )  ; 
sleep  (  1  )  , 
i 


/♦  En'er  Cr  i  i  n.o  Region  •/ 


/•  Exit  Criticol  Region  •/ 


consumer  (nuiu; 
i  n  t  n  u  m  ; 

) 

i  n  t  i  ,  c  o  n  t  ; 

for  ( i  =  0;  i  <  N ;  i ++ )  { 


cont  =  FALSE; 

while  (!  cont)  J  /•  woit  for  a  full  buffer  •/ 

s_ I oc  k  ( 4  f  u  I  I  _  I  k  )  ; 

if  (full  >0)  | 

cont  =  TRUE; 
f  u  I  I  —  ; 

i 

s_unl ock  (  4  f  u  I  I  _  I  k  )  ; 

f 

s_lock  (4cons_lk);  /•  Enter  Critical  Region  •/ 

printf  ("Message  Number:  /5d\n",  buf  f  e  r  [out  ]  .  nsgnum)  ; 
printf  ("From  Producer  Number:  /5d\n",  bu  f  f  e  r  [out  ]  pr  num  )  ; 
printf  ("By  Consummer  Number.  Sld\n"  ,  num); 
fflush  (stdout), 
out  =  (out  +  1 )  %  N ; 

s.un lock  (tcons.l k) ;  /  *  Exit  Critical  Region  */ 


s_lock  (tempt  y_ Ik); 
emp  t  y  +  + ; 

s.un lock  (4empty_lk) 
sleep  ( 1 ) ; 


/*  Exit  Critical  Region  */ 

/•  Increment  #  of  empty  buffers 


ma  in  (  ) 

) 


in  =  0 ; 
out  =  0 ; 

/* 

empty  =  N ; 
full  =  0  ; 

/* 

/*  Start  producers 

c  o  b  e  g  i  n 

producer 

(0)  : 

producer 

(1). 

consume  r 

(0)  ; 

consume  r 

(1  )  : 

c  o  e  nd 

/•  pointer  to  buffers  •/ 

/*  All  buffers  ore  empty  •/ 
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4.2.7  Readers/Writers 

Example  30  shows  a  solution  to  the  Readers /Writers  problem.  This  problem  is  similar  to 
the  Bounded  Buffer  problem.  There  are  a  number  of  readers  and  writers.  Each  reader 
wishes  to  read  a  data  structure  and  each  writer  wishes  to  write  to  the  data  structure.  In 
this  problem,  any  number  of  readers  may  read  the  data  structure  at  a  time.  A  reader  does 
not  change  the  data  structure.  However,  no  reader  may  access  the  data  structure  while  a 
writer  is  writing  and  only  one  writer  may  write  at  a  time.  This  is  a  problem  of  mutual 
exclusion.  In  this  example,  the  shared  data  structure  is  the  integer  “value”.  A  reader 
will  read  and  print  “value”.  A  writer  simply  increments  “value”  by  one.  The  variable 
“read_count”  holds  the  number  of  readers  currently  reading  “value”.  The  variable  “wrt” 
is  a  flag,  “wrt”  is  TRUE  if  a  writer  is  writing  and  FALSE  otherwise.  The  lock  “writer  Jk” 
ensures  mutual  exclusion  on  both  variables.  Each  reader  begins  by  obtaining  the  lock  and 
checking  “wrt”  to  see  if  a  writer  is  writing.  If  “wrt”  is  FALSE,  the  reader  increments 
“read-count”  and  reads  “value”.  A  reader  only  prints  “value”  if  it  has  changed  since  last 
read.  After  reading  “value”,  a  reader  will  decrement  “read_count”.  A  writer  must  check 
“wrt”  to  see  if  any  other  writer  is  writing  and  “read-count”  to  see  if  there  are  any  readers 
reading.  If  “wrt”  is  FALSE  and  “read-count”  is  zero,  a  writer  may  proceed.  The  w’riter 
will  then  set  “wrt”  to  TRUE.  After  the  writer  is  finished,  he  will  set  “wrt”  to  FALSE. 
Again,  a  cobegin-coend  block  was  used  to  create  each  reader  and  writer  process. 
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Example  30 


#  i  n c I ude  <  s  t  d  i  o . h> 

)jf  include  <paral  I  e  I  /»  i  c  rotosk  .  h> 
find  ude  <parol  le l/para I  I e I  . h> 
jfdefine  TRUE  1 
jjfdefine  FALSE  0 

/•  This  program  demonstra; es  a  solution  to  the  Readers/Writers  problem. 

/•  In  this  problem,  there  are  three  readers  and  two  writers.  The 
/•  readers  will  read  the  variable  "value"  and  if  it  has  changed  since  they 
/•  last  read  it,  they  will  print  its  value.  The  writers  constantly  try 
/•  to  update  the  variable  "value".  This  solution  will  allow  as  mony 
/«  readers  to  access  "value"  as  wish.  However,  no  readers  moy  occess  the 
/•  "value"  when  a  writer  is  updating  it,  and  only  one  writer  may  update 
/•  "value"  at  a  time.  The  variable  " read.count "  tells  how  many  readers 
/•  are  reading  the  variable.  The  variable  "wrt"  is  TRUE  if  a  writer  is 
/»  writing.  A  reader  will  proceed  only  if  "wrt”  is  FALSE.  A  writer  will 
/»  proceed  only  if  "wrt"  is  FALSE  and  "reod.count"  is  zero.  The  lock 
/*  "writer_lk  is  used  to  ensure  mutual  exclusion  on  both  "reod.count"  and 
/*  "wrt". 

shared  slock_t  w  r i t  e  r  _ I k ; 

shared  int  value,  read.count ,  wrt; 

reader  (num) 
int  num; 

) 

int  oldvalue,  in; 
oldvalue  =  0; 
in  =  FALSE; 


for  (  ;  ;  )  {  /•  forever  do  •/ 

in  =  FALSE; 

while  (!  in)  \  /»  while  I  con  not  enter  my  crtical  section,  spin  •/ 

s_lock  ( Jew  r  i  t  e  r_  I  k  )  ; 

i  f  (  !  w  r  t )  j  /  »  Are  ony  writers  writing?  •/ 

i n  =  TRUE ; 
reod.count ++ ; 

I 

s.un I ock  (twr  i  te  r_ Ik); 

I 

if  (value  !=  oldvalue)  J  /•  If  value  has  changed,  print  it  */ 
oldvalue  =  value; 

printf  ("Reader  %d  saw  value  change  to  %d\n",  num,  oldvalue); 


s.lock  (  Jew  r  i  t  e  r  _  I  k  )  ; 

reod.count — ; 

s.un  I  ock  (  Jew  r  i  t  e  r  _  I  k  ) 


/•  Exit  Critical  Section  */ 


writer  (  ) 


*  O  r  (  ;  ;  )  j 

in  =  FALSE, 

while  (I  in)  )  /•  while  I  can  not  enter  Criticol  Section,  Spin  •/ 

s.lock  (Jrwriter_lk), 

if  ((!  wrt)  tt  ( reod.count  ==  0))  )  /•  Con  I  write?  •/ 

i n  =  TRUE , 
wrt  =  TRUE , 


» 


I 


k  *w»  ^-  sj*  ^4«* 


lock  (twr i  ter_i k)  ; 


v a  I ue+i ; 


/•  Update  value  •/ 


s.lock  (twri ter.l k) ; 

wrt=  FALSE;  /•  Exiting  Critical  Section  •/ 

s_un I oc  k  (Jcwriter_lk); 


main  ( ) 


value  =  0 ; 
read.count  =  0; 
wrt  =  FALSE; 

s.init.lock  (4*riter.lk); 

/.  Start  Readers  and  Writers  •/ 
cobeg i n 

reader  (0); 
reader  (1); 
reader  (2); 
writer  ( ) ; 
writer  (  )  ; 
coend 


v/wcv?  .v.  •  ■'■.wa’aIa;. 


4.2.8  Matrix  Multiply 


Example  31  shows  a  Matrix  Multiply  program.  This  program  multiplies  two  6  by  6  ma¬ 
trices.  A  and  B,  to  produce  matrix  C.  This  means  the  each  row  of  matrix  A  is  multiplied 
by  each  column  of  matrix  B.  This  is  an  example  of  data  partitioning.  This  solution  di¬ 
vides  the  data  by  rows  of  matrix  A.  Each  process  will  multiply  one  row  of  matrix  A  by 
every  column  of  matrix  B  to  produce  a  new  row  in  matrix  C.  This  requires  six  processes 
since  matrix  A  has  six  rows.  Each  process  executes  the  routine  “row”  which  accomplishes 
the  multiplication.  All  six  processes  are  again  created  by  a  cobegin-coend  block.  This 
program  is  very  simple  and  is  used  to  show  the  cobegin-coend  construct's  capability  to 
handle  data  partitioning.  However,  notice  that  the  program  needed  to  know  the  number 
of  rows  in  matrix  A  before  execution.  This  shows  the  cobegin-coend’s  weakness  in  a  dy¬ 
namic  environment.  This  weakness  could  be  overcome  in  this  problem  by  using  m_next. 
m_next  could  keep  track  of  the  number  of  rows  which  have  been  multiplied.  A  process 
could  decide  to  multiply  another  row  of  matrix  A  by  checking  the  value  of  m_next. 


/ . 

/•  Exomple  31 

/•♦ . 
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^include  <s  t  d i o . h> 
ifdefine  N  6 

shored  int  c[N][N],  o[N][N],  b[N][N]; 

/•  This  procedure  multiplies  row  i  of  matrix  A  by  •/ 

/•  each  column  of  matrix  B  and  stores  the  result  in  */ 

/•  inrowiofmotrixC.  *  / 

void 
row  ( i ) 
int  i  ; 

I 

int  j , k ; 

f  o  r ( j  =0 ;  j  <N  ,  j  ++  )  j 
c  [  i  ]  [  j  ]  =  0  ; 
f  or ( k  =  0 ;  k<N;  k  +  +) 

C[i][j]  +=  o[i][k]  •  b [ k  )  [ j  ]  ; 


/•  This  procedure  reads  in  two  6  by  6  matrices  *  / 
void 

i  n i  t _ma  t  r i ce  s  ( ) 

i 

int  i , j ; 

printf  ("ENTER  MATRIX  A  and  B  by  ROWS\n\n"); 
for  ( i =0 ;  i <N ;  i ++ )  ) 

printf  ("ENTER  ROW  Zd  :  ",  i+1); 

sconf  (  "5Sd%d%d55d%d%d%d%d%d%d%d3d“  ,  *a  [  ■  ]  [  0  ]  ,  4o[i][l],  *  [  i  ]  t  2  ]  , 

*a[i][3],  &  a [  i  ] [ 4  ]  .  4o[i][5],  *b[,][0],  *b[i][l],  *b[i][2] 
fc  b  [  i  j  [  3  j  ,  *  b  [  i  ]  [  4  ]  ,  4  b  [  i  ]  [  5  ]  )  ; 
printf  (  "\n " )  ; 

I 

fflush  (stdout); 


This  program  multiplies  two  N  by  N  matrices.  A  and  B  to  get 
matrix  C.  The  program  is  executed  in  parallel  by  creating 
N  processes  with  a  cobegin.  Each  child  process  will  multiply 
row  i  of  matrix  A  by  each  column  of  matrix  B  to  get  row  i  of 
matrix  C.  where  i  is  passed  to  the  process  All  three 
Matrices  are  in  shored  memory  for  each  process  to  access 
Since  each  process  is  writing  to  a  seporate  row  in  C.  no 
synchronizoton  to  access  memory  is  neccessary. 


mom() 


void  mi  l_i»ol  rues  (i.  row  (); 
int  i  .  i  , 

init_matrices  (). 

c  o  b  e  g  i  n 

r  ow  ( 0  )  . 
row  (  1  )  , 
row  ( 2  )  . 
row  ( 3  )  . 
r  c  w  (  4  )  , 
row  (  5  )  . 


/•  read  in  matrices  •/ 


% 


print  out  each  matri 


printf  ("  M 

p  r  i  n  t  f  (  "  _ 

for  ( i =0 :  i <N 
for  ( j  =0 ; 

_  -  :  _  a  i 


MATRIX  A 


MATRIX  B 


MAT R I  X  C\n" )  ; 
_ \n\n") 


v.  ;  i++) 

for  ( j  =0 ;  j  <N ;  J  ++ ) 

printf  (  "?53d  ",  a(  i  ]  [  j  ]  )  ; 
p  r  i  r.  t  f  (  "  "  )  . 

for  ( j  =0  ;  j  <N ;  j  ++ ) 

printf  (  "7.3d  ",  b[  i  ]  [  j  ]  )  ; 
printf  ("  ")i 

for  ( j  =0  ;  ] <N ;  j  ++ ) 

pr  i  nt  f  (  "7.3d  ",  c  [  i  ]  [  j  ]  )  ; 


i][j]>. 


r . 

printf  ( " 
for  ( j  =0 ; 


for  ( j  =0 ;  j  <N ; 

p  r i n  t  f ( "%3d 
p  r i n  t  f ( "\n  "  )  ; 


w> 


5  Synchronization 


Synchronization  mechanisms  allow  one  process  to  affect  the  execution  of  another  process. 
There  are  two  types  of  process  synchronization.  First,  a  process  can  delay  until  a  specific 
condition  is  true.  This  is  referred  to  as  “conditional  synchronization’’.  Second,  a  synchro¬ 
nization  mechanism  can  be  used  to  ensure  mutual  exclusion.  Section  3.10  demonstrates  the 
s.lock  routine  which  can  be  used  to  ensure  mutual  exclusion  by  encapsulating  a  section  of 
code  by  the  commands  s_lock  and  s_unlock.  The  Bounded  Buffer  problem  in  section  4.2.6 
demonstrated  conditional  synchronization.  In  the  Bounded  Buffer  problem  a  producer  can 
only  proceed  if  the  amount  of  empty  buffers  is  greater  than  zero.  Only  a  consumer  can 
release  an  empty  buffer  and  so  the  consumers  effect  the  execution  of  producers  through  a 
specific  condition.  Synchronization  of  processes  is  based  on  interprocess  communication. 
For  process  A  to  affect  process  B,  process  A  must  communicate  some  condition  to  process 
B.  Communication  between  processes  on  the  Balance  8000  is  based  on  a  shared  memory 
architecture.  This  means  that  multiple  processes  communicate  by  reading  and  writing  to 
shared  data  structures  in  memory.  Thus,  synchronization  of  processes  in  a  shared  memory 
architecture  is  based  on  setting  conditions  in  memory  that  multiple  processes  can  detect. 
Although  the  Balance  8000  allows  programmers  to  create  a  large  number  of  locks,  its  lock¬ 
ing  routines  are  based  on  a  set  of  physical  hardware  locks.  These  physical  locks  ensure 
mutual  exclusion  on  the  software  locks  which  the  programmer  has  created  by  performing 
test-and-set  operations.  This  ensures  that  multiple  processes  can  not  obtain  the  same  soft¬ 
ware  lock  at  the  same  time.  How  does  a  programmer  use  shared  memory  to  synchronize 
multiple  processes  without  the  help  of  a  hardware  test-and-set  operation?  The  following 
two  examples  give  software  solutions  to  the  mutual  exclusion  problem.  After  the  mutual 
exclusion  problem  has  been  solved,  conditional  synchronization  can  be  achieved.  This  is 
accomplished  by  placing  the  condition  in  shared  memory  and  making  it  mutually  exclusive. 
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5.1  Peterson’s  Solution 


Example  32  is  a  software  solution  to  the  mutual  exclusion  problem  as  presented  by  Peterson 
[2].  In  this  example,  two  processes  wish  to  increment  the  same  counter.  The  routine 
“counts”  increments  the  counter  by  one  and  prints  out  its  value.  The  routines  “lock”  and 
“unlock”  provide  mutual  exclusion  on  this  operation  using  only  shared  memory.  In  this 
solution,  each  process  shares  three  variables.  Two  flags  are  used,  one  for  each  process, 
to  indicate  whether  the  process  wishes  to  enter  its  critical  section.  The  integer  “turn”  is 
used  to  indicate  which  process  may  proceed  into  its  critical  section.  The  routine  “lock" 
is  called  immediately  before  a  processes  critical  section  and  the  routine  “unlock”  is  called 
immediately  after  the  critical  section.  The  routine  “lock”  sets  the  process’s  flag  to  TRUE 
indicating  it  wishes  to  enter  its  critical  section.  “lock”  then  sets  the  value  of  “turn”  to 
designate  the  other  process.  If  “turn”  designates  the  other  process  and  the  other  process’s 
flag  is  TRUE,  then  a  process  spins  until  it  is  either  their  turn  or  the  other  process  resets  its 
flag.  Notice  that  if  only  one  process  wishes  to  enter  its  critical  section,  then  its  neighbor’s 
flag  will  be  false  and  it  can  proceed.  If  both  processes  try  to  enter  the  critical  section  at  the 
same  time,  “turn”  will  point  to  only  one  of  them  and  that  process  will  proceed.  However, 
after  that  process  is  finished,  it  resets  its  flag  to  FALSE  and  the  other  process  may  enter 
its  critical  region.  This  solution  is  a  strongly  fair  solution  since  a  process  will  only  wait  at 
most  one  turn  before  it  can  enter  its  critical  section. 
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/•••••••• . / 

/•  Example  32  •/ 

/ . / 

^include  <  s  t  d  i  o  .  h  > 

^define  TRUE  1 
jjf  d  e  f  i  n  e  FALSE  0 

/•  This  program  is  a  software  solution  to  the  mutual  exclusion  •/ 
/•  problem  as  presented  by  Peterson.  Two  processes  wish  to  •/ 

/•  increment  a  counter.  To  ensure  mutual  exclusion  each  process  •/ 

/»  calls  the  function  lock  before  entering  its  critical  section  •/ 
/•  the  function  unlock  after  exiting  its  critical  section.  The  •/ 
/•  processes  share  two  variables,  flag  and  turn.  flag  is  an  »/ 

/•  array  of  two  flogs,  one  for  each  processor.  The  flag  informs  •/ 
/•  the  other  process  that  you  wish  to  enter  your  critical  •/ 

/»  section.  To  enter  its  criticol  section,  a  process  sets  its  */ 

/«  flag  to  TRUE  and  sets  turn  to  designate  the  other  process.  •/ 

/•  If  the  other  process  wants  to  enter  its  critical  section  and  •/ 

/•  its  their  turn,  then  spin.  Otherwise,  enter  your  critical  •/ 

/•  section.  After  exiting  your  critical  section,  set  your  flog  •/ 

/•  to  FALSE.  •/ 


shared 

int  counter,  f 1 og [ 2 ] 

lock  (  p 

r  n  urn  ) 

i  n  t 

prnum; 

i  n  t 

j  : 

flag[prnum]  =  TRUE; 

j  = 

(prnum  +  1)  7.  2; 

turn 

=  j  ; 

wh  i  1 

e  (  (  f  1  ag  [  j  ]  )  !c!c  (  t  u  r 

i 

unlock 

(prnum) 

i  n  t 

prnum; 

f  1  a  g  [  p  r  o ]  =  FALSE; 

l 

count  s 

(prnum) 

i  n  t 
s 

prnum; 

i 

i  n  t 

i  , 

f  o  r 

(  i  =  0 ;  i  <  10;  i ++ ) 

/•  I  want  to  enter  my  critical  section  •/ 


lock  (prnum); 
counter  ++; 

pr  ntf  ("Process  55 d  Increments  Counter  to  55d\n" 
ffiush  (stdout); 
unloci'  (prnum); 


prnum,  counter) 


ma  in  ( ) 

1 

counter  =  0; 

c  o  b  e  g  i  r. 

counts  (0); 
counts  ( 1 ) ; 
coend 
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5.2  Eisenberg  and  McGuire’s  Solution 


m 


Example  32  showed  Peterson’s  solution  to  the  mutual  exclusion  problem  for  two  processes. 
Example  33  shows  a  software  solution  for  multiple  processes  as  presented  by  Eisenberg  and 
McGuire  [2].  In  this  example,  five  processes  wish  to  increment  the  shared  counter.  Again, 
the  routines  “lock”  and  “unlock”  are  used  to  ensure  mutual  exclusion  by  placing  “lock” 
at  the  beginning  of  the  critical  section  and  “unlock”  immediately  after  the  critical  section. 
Each  process  shares  six  variables:  an  array  of  five  flags  which  designate  the  state  of  a 
process  (IDLE,  WANTIN,  or  IN.CS)  and  the  integer  “turn”  which  designates  a  process 
that  may  enter  its  critical  section.  This  solution  is  more  complicated  than  Peterson’s. 
The  routine  “lock”  sets  the  flag  of  a  process  to  WANTIN  and  places  the  value  of  “turn” 
in  a  local  variable.  The  process  then  spins  until  the  local  variable  indicates  that  it  is  its 
turn.  At  this  point,  the  process  sets  its  flag  to  IN_CS.  However,  since  a  local  variable 
was  used  for  the  value  of  “turn”,  the  process  does  not  know  which  other  processes  might 
be  in  their  critical  sections.  So,  the  process  now  spins  until  no  other  process  is  in  the 
state  IN.CS-  At  this  point,  the  process  checks  to  see  if  “turn”  points  to  it  or  to  an  IDLE 
process.  If  it  is  its  true,  the  process  enters  its  critical  section.  Otherwise,  the  process  gets 
a  new  value  of  “turn”  and  tries  again.  The  “unlock”  routine  is  executed  only  by  a  process 
wrhich  is  entering  or  exiting  its  critical  section,  “unlock”  sets  “turn”  to  point  to  the  next 
nonJDLE  process  in  an  ordered  sequence  and  sets  the  flag  of  the  exiting  process  to  IDLE. 
The  “unlock”  routine  ensures  strong  fairness  in  the  solution. 


A  *  .  *  *  i'.  r.  rf*.  wT. 
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Example  33  • , 


§  include  <  s  t  d  i  o  .  h  > 
#def  i  ne  IDLE  0 
#def  i ne  WANT  1 N  1 
#def i ne  IN_CS  2 
|de  f i ne  N  5 


This  program  shows  the  software  solution  to  the  mutuol  exclusion 
problem  as  presented  by  Eisenberg  and  McGuire.  There  are  N 
processes  which  wish  to  increment  a  counter.  To  ensure  mutual 
exclusion  while  incrementing  the  counter,  each  process  colls  the 
function  "lock"  before  entering  its  critical  section  and  calls 
the  function  "unlock"  offer  leaving  its  criticol  section  All 
processes  share  an  array  of  flags,  one  per  process.  A  flag  can 
be  in  one  of  three  states,  IDLE,  WANTIN,  IN_CS.  They  also  share 
the  variable  turn.  Notice  that  a  process  can  enter  its  critical 
section  only  if  no  other  process  is  in  its  criticol  section. 

Also  note  that  the  value  of  turn  is  modified  only  when  o  process 
enters  or  exits  its  critical  section.  Once  a  process  has  set 
its  flag  to  I N_CS  (thinking  that  no  one  else  is  in  their 
critical  section),  it  waits  until  turn  points  to  it  or  the 
process  which  turn  points  to  is  idle. 


shared  int  counter,  flag[N],  turn; 


lock  (prnum) 
int  prnum; 


n  t  j  ; 


flagfprnum]  =  WANTIN; 
j  =  turn; 

while  (j  ! =  prnum)  J 


/•  I  wont  in  my  critical  section  •/ 


e  (j  !  =  prnum)  J  /•  Wait  until  everyone  between  •/ 

f  (flag[j)  !=  IDLE)  /*  me  and  turn  are  IDLE  •/ 

j  =  turn; 


else 

j  =  (  j  +  1  )  %  N  ; 


flag[prnum]  =  IN  CS,  /  *  I  am  entering  my  critical  section  •/ 

j  =  0; 

while  ((j  <  N  '  Jr  4  [ ( j  ==  prnum)  ||  ( f  I  a  g [ j  ]  '=  I  N_CS ) ) ) 

j  ++  ; 

j  while  ( ( j  <  N;  ||  ((turn  !=  prnum)  kk  ( f I og[ turn]  !=  IDLE))); 
turn  =  prnum. 


unlock  (prnum) 
int  prnum; 


"I  J  • 


j  =  (turn  +  1  )  %  N  , 

while  ( f I ag [ j ]  ==  IDLE) 
j  =  (  j  *  1  )  3  N  ; 

t  u  r  n  =  j  , 

fiag[prnum]  =  IDLE, 


/•  Give  turn  to  next  in  'ine  •/ 


/•  I  am  out  of  my  critical  section  •/ 


counts  (prnum) 
i  n  I  prnum; 

) 

int  i  . 


- 


ft 


b 


for  (  i  =  0 ;  i  <  N ;  i ++ )  } 

lock  ( p  r  n  um  )  ; 
couote r ++ ; 

printf  ("Process  %d  Increments  Counter  to  %d\n' 
fflush  (stdout  )  ; 
unlock  ( p  r  num )  ; 


main  ( ) 

{ 

i  n  t  i  ; 

counter  =  0; 

turn  =  0 ; 

for  (i  =0;  i  <  N  ;  i ++ ) 
f I og[  i  ]  =  IDLE; 

cobegin 

counts  (0); 
counts  ( 1 ) ; 
counts  (2); 
counts  (3), 
counts  ( 4 ) . 

coend 


prnum,  counter) 


/•  set  everyone  to  idle  •/ 


| 

I 


\vyvyvv 


prforks  is  called  each  time  a  new  statement  is  found  within  o 
c obe g  i  n-c o e n d  block.  The  routine  inserts  the  code  required  to 
fork  a  new  process  and  add  the  P1D  of  each  child  process  to  an 
on-going  list.  An  array  of  print  statements  (the  code  to  be 
inserted)  is  created  using  the  structure  'entry'.  The  paramenter 
’col’  holds  the  column  to  begin  printing  the  inserted  code. 

forks  (col) 

i n  t  col; 

i  n  t  j  .  i  ; 

static  struct  entry  stmt[4]  =  J  )  "pid  =  fork  ();\n\0"j, 

}  “  i  f  (pid  !=  0 ) \ n\0 " j  , 

)"  p  i  do r ray [ j j++]  =  pid;\n\0"|, 
Pi  f  (pid  ==  0)  { \n\0 "  {  j  ; 

for  (j  —  0;  j  <4;  j  ++ )  j 

for  (i  =  0;  i  <  col;  i++)  /•  move  to  column  col  •/ 

putc  (’  ' ,  output); 

fprintf  (output,  stmt[j].!n);  /•  print  fork  logic  •/ 

i 

fprintf  (trout,  New  Statement  and  Fork  ••*\n”); 


The  routine  push  will  enter  a  new  symbol  on  the  top  of  the  stock 
push  returns  a  1  if  successful  and  a  0  if  stock  Overflow  is  found 
If  Overflow  is  found,  UPPERBOUND  may  be  reset  in  the  fdefine 
statement  at  the  beginning  of  this  program. 


push  ( s  ymbo I  ,  In) 
char  syrobo I ; 
i  n  t  In; 


symbol  to  be  pushed  on  stack 
I  i  ne  number  where  symbol  was  found 


f  p  r  i  n  t 
i  f  (  s  t  k 
f  p  r 
ret 

j 

else  } 
s  t  k 
f  pr 
f  p  r 
s  t  k 
st  k 
r  e  t 


i  (trout,  "Entered  Push  rout i ne\n") ; 
.top  >=  UPPERBOUND)  J 

i ntf (stderr ,  "Overflow  on  Stack\n"); 
urn  (  0  )  ; 


/»  OVERFLOW  ?  •/ 

/•  Print  error  message  •/ 


top  +  +;  /*  advance  top  •/ 

intf  (trout,  "Top  %d\n",  stk.top); 

intf  (trout,  "Pushed  stack  char:  55c  at  line  %d\n",  symbol.  In); 

.  s ym [ s t k .  t o p ]  =  symbol;  /•  add  symbol 

. I num[stk . top]  =  In;  /  *  addcurrent  line# 

urn  (  1  )  ; 


/•  add  symbol  •/ 

/  *  add  current  line  #  */ 


/•  The  empty  routine  returns  1  if  the  stack  is  empty  and  0  otherwise. 
/•  The  choracter  ’ i '  indicates  an  empty  stack. 


•/ 

•/ 


empty  () 

I 

return  ( s t k  sym [ s t k  .  t op ]  ==  1 1 ’  )  ; 

i 


/• 

The 

routine  pop 

will  delete  the 

top 

s  ymbo 1  on 

the  stock. 

•/ 

/* 

pop 

returns  a  1 

if  the  operation 

i  s 

successful 

and  a  0 

•/ 

/* 

i  f 

Underflow  is 

found , 

*/ 

POP  (  ) 

i 

fprintf  (trout,  "Entered  Pop  routine\r");  /*  Print  statements  to  • 

if  (stk.top  ==  LOWERBOUND)  J  /•  trout  trace  the  • 

f p r i n t f ( s t d e r r ,  "Underflow  on  Stack\n");  /•  stack  operations  • 

return  (0); 

i 

else  } 

fprintf  (trout,  "Poped  stock  char:  Zc  at  line:  J5d\n",  stk.symfstk.top] 
st  k .  I num[ s  t  k .  top] )  ; 

stk.top — ;  /«  delete  top  symbol  »/ 

return  (1); 


finclude  <sys/woit.h> 

^include  <ctype.h> 
f  include  <strings.h> 

^include  <s  t  d i o . h> 

|de  f  i ne  TRUE  1 
f de  f  i ne  F ALSE  0 

| define  LOWERBOUND  0  /•  lowerbound  on  stack  */ 

|define  UPP ERBOUND  99  /»  uppe  rbound  on  stock  */ 


/.  FILES: 

•/ 

/•  input  points 

to  the 

C  source 

file 

•/ 

/•  output  points 

to  the  C  source 

file  after  precompi 

lot  ion 

•/ 

/♦  trout  points 

t  o  a  f 

ile  containing  a  trace  of  the 

stock  operations 

•/ 

FILE  (input,  (output.  • 

trout; 

i n  t  1 c  ou  n  t  ; 

/• 

count  number  of  lines  in  source  file 

•/ 

char  1  i n e [ 80 ]  ; 

/• 

buffer  to  read  one  1 

i ne  at  a  t i me 

•/ 

struct  stack  { 

/* 

The  stack  is  used  to 

search  for  the 

•/ 

char  sym[100]; 

/• 

end  of  a  statement. 

When  the  stock 

♦/ 

int  1 n  um [ 1 00 ] : 

/• 

is  empty  the  end  of 

the  statement  has 

*/ 

i n  t  top; 

/• 

been  found.  top  poi 

nts  to  the  top  of 

•/ 

{  s  t  k  , 

/* 

the  stack,  sym  holds 

the  next  symbo 1 

•/ 

/• 

to  locate,  and  Inum 

tells  on  which 

•/ 

/• 

line  the  search  began. 

•/ 

struct  entry  { 
char  I  n  [  80  ]  ; 

I  : 


/•  entry  ol lows  the  creation  of  an  array  •/ 
/*  of  print  statements.  Each  statement  •/ 
/•  must  be  less  than  80  characters.  •/ 


vwv 
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The  Balance  8000  provides  a  complete  concurrent  programming  environment.  The  pro¬ 
grammer  has  all  the  required  primitives  for  process  creation,  synchronization,  termination. 
The  programmer  has  the  responsibility  to  ensure  that  every  use  of  these  primitives  is  con¬ 
sistent  and  correct.  A  complete  investigation  into  the  memory  aspects  of  the  Balance 
8000  is  needed.  The  creation  of  a  message  sending  mechanism  would  also  be  an  interest¬ 
ing  research  topic.  This  mechanism  would,  of  course,  be  based  on  shared  memory.  The 
concurrent  programming  routines  in  the  Parallel  Programming  Library  are  also  available 
for  Pascal.  Appendix  B  discusses  the  implementation  of  the  cobegin-coend  construct  in 
Pascal.  The  software  community  has  a  fair  amount  of  research  and  implementation  work 
to  accomplish  in  order  to  meet  the  multiprocessing  capabilities  provided  by  the  computer 
hardware  community. 


6  Conclusion 


The  objective  of  this  paper  was  to  investigate  and  document  the  concurrent  environment 
of  the  Sequent  Balance  8000  Multiprocessing  System.  The  paper  concentrates  on  the 
process  creation  and  control  mechanisms  provided  by  the  DYNIX  Parallel  Programming 
Library.  A  precompiler  is  also  introduced  to  implement  the  parallel  programming  construct 
“cobegin-coend”.  The  fork  and  m_fork  routines  are  DYNJX  routines  for  process  creation. 
The  precompiler  implemented  the  cobegin-coend  construct  using  the  fork,  exit,  and  wait 
routines.  The  m_fork  routine  may  seem  very  limited  in  its  capabilities,  however,  when 
used  for  data  partitioning  applications,  its  serves  its  purpose.  The  m_fork  routine,  like 
cobegin-coend,  is  based  on  the  fork  routine.  The  fork  routine  is  a  simple  and  fl  xible 
routine  for  process  creation.  However,  the  coding  of  forks,  exits,  and  waits  can  become 
confusing.  It  is  not  a  clear  mechanism  for  denoting  process  creation.  Each  call  to  fork 
also  requires  approximately  50  milliseconds.  This  suggests  that  process  creation  should 
be  limited  to  only  those  applications  whose  individual  process  run  times  exceed  the  time 
to  execute  each  fork.  Although  many  applications  benefit  from  the  fact  that  a  fork 
operation  copies  the  parents  total  environment  to  the  new  child  process,  this  should  not 
be  the  default  and  serves  only  to  waste  time  and  memory.  What  is  needed  is  a  mechanism 
which  copies  only  the  section  of  code  which  is  to  be  executed  by  the  new  process  and  any 
other  explicitly  referenced  information.  The  cobegin-coend  construct  is  a  very  easy  and 
clear  mechanism  for  process  creation,  but  loses  some  of  the  flexibility  of  the  fork  operation. 
An  extension  to  the  cobegin-coend  construct  is  needed  to  add  the  dynamic  features  of  the 
fork  operation.  A  type  of  optional  statement  guard  is  suggested  for  the  cobegin-coend 
construct.  This  guard  could  be  used  to  determine  process  creation  and  carry  a  parameter 
which  determines  the  number  of  processes  to  be  created. 

The  DYNIX  Parallel  Programming  Library  also  provides  many  .  mtines  for  process  syn¬ 
chronization.  These  mechanisms  can  be  used  to  solve  both  the  mutual  exclusion  and 
conditional  synchronization  problems.  However,  all  these  primitives  are  built  upon  the 
Balance’s  locking  mechanism.  This  paper  has  already  shown  that  this  mechanism  is  only 
weakly  fair.  This  means  that  no  strict  order  is  maintained  on  which  process  is  next  to 
obtain  a  lock,  but  that  each  process  will  eventually  obtain  the  lock.  The  locking  routines 
of  DYNIX  are  very  dangerous.  The  programmer  has  the  responsibility  for  explicitly  and 
consistently  coding  every  lock  and  unlock  command.  This  can  also  lead  to  difficulty 
in  maintenance.  A  Monitor  capability  is  suggested  in  which  any  shared  resource  can  be 
encapsulated  in  one  location  along  with  any  valid  operations  on  that  resource. 
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/•  prwaits  is  called  at  the  end  of  a  cobegin  -  coend  block.  •/ 
/•  The  rountine  inserts  the  code  needed  to  perform  the  wait  system  •/ 
/•  call  into  the  updated  C  source  file  A  loop  is  created  in  the  */ 
/•  new  source  file  to  perform  a  wait  operation  for  each  child  */ 
/•  process  Within  the  loop,  the  parent  receives  the  PID  and  the  •/ 
/*  status  of  each  child  process.  If  the  status  is  nonzero,  then  on  •/ 


/•  error  hos  occurred  and  the  array  pidarray  is  searched  to  find  the  •/ 
/•  number  of  the  statement  which  returned  with  the  error.  A  message  •/ 


/*  is  printed  giving  the  statement  number  relative  to  the  cobegin  •/ 
/•  block  An  array  of  print  statements  (the  inserted  code)  is  •/ 
/•  created  using  the  structure  'entry'.  The  poramenter  ’n’  holds  •/ 
/•  the  number  of  wo i t s  (loop  iterations)  to  perform.  'col'  holds  •/ 
/•  the  column  number  to  stort  the  code  for  a  structured  appearance.  •/ 


prwaits  (n.  col) 
i n  t  n ,  col; 

i 

i  n  t  j  .  i  ; 

static  struct  entry  stmt[9)  =  j  |"for  ( i i  =  0 ;  ii  <  %d ;  i i ++ )  j\n\0"j, 

J ’’  pid  =  wait  (&status);\n\0"j, 
j"  if  (status)  j \n\0 " j  , 

}"  j  j  =  0 ; \n\0 " (  , 

while  (pid  !=  p i dor  ray [ j  j  ] )\n\0" | , 

i "  j  j  ++ i \n\0 " j  . 

)"  pr  intf  (Y'Error  on  Stmt  %Zd  in  cobegin  bl ock\\n\" ,  j  j  )  ;\n\0"( 

}•'  |  \n\0"  j  , 

i  "  i \ n\0  i  j; 

fprintf  (trout,  "Prwaits  is  called  number  of  Waits  Zd\n".  n); 

for  (i  =  0;  i  <  col;  i++)  /*  move  to  correct  column  to  insert  code 

putc  (’  ’,  output); 

fprintf  (output,  stmt [0] . In,  n);  /•  insert  ’for  loop'  •/ 

f  o  r  (  j  =  1  ;  j  <  9 ;  j  ++ )  j 

for  (i  =0;  i  <  co I ;  i++)  /*  move  to  column  'col'  •/ 

putc  (’  ,  output); 

fprintf  (output,  stmt[j].ln);  /*  insert  woit  logic  •/ 


/*  The  routine  forkstmts  is  called  when  the  beginning  of  o  •/ 
/•  cobegin  -  coend  block  is  found.  The  overall  function  •/ 
/•  of  this  routine  is  to  separate  the  statements  within  •/ 
/•  the  cobegin  -  coend  block  and  to  call  the  appropriate  •/ 
/•  routines  to  insert  the  fork,  exit  and  wait  code.  This  »/ 
/♦  routine  is  recursive,  so  that  if  it  finds  the  beginning  •/ 
/•  of  a  cobegin  -  coend  block,  it  calls  itself.  forkstmts  */ 
/«  uses  the  stack  to  find  the  end  of  a  statement  It  */ 
/•  initially  assumes  the  end  to  be  a  and  thus  places  »/ 
/•  that  character  on  the  stack.  If  a  is  found  before  •/ 
/«  the  end  of  the  statement  is  found,  then  a  'j'  replaces  •/ 
/»  and  will  now  indicate  the  end  of  the  statement.  •/ 
/•  every  time  a  character  is  read  that  matches  the  top  of  •/ 
/•  the  stack,  then  the  top  of  the  stack  is  deleted.  If  */ 
/*  the  stack  is  empty,  then  the  end  of  the  statement  is  •/ 
/•  found.  A  switch  statement  is  used  to  check  each  •/ 
/•  character  that  is  read.  The  parameter  ‘col’  holds  the  */ 
/•  column  number  where  the  cobegin  was  found.  This  is  used  »/ 
/•  to  create  a  structured  appearance  when  inserting  code.  •/ 
/»  forkstmts  will  coll  the  push  and  pop  routines  inside  •/ 
/»  if  statements  This  is  to  check  for  errors  If  an  •/ 
/•  error  is  found,  forkstmts  returns  a  0.  otherwise  it  •/ 
/♦returns  a  1.  •/ 


forkstmts  (col) 


i  n  t 

col; 

i  n  t 

nocoend ; 

/• 

True 

when  no  coend  has  been  found  »/ 

i  n  t 

dostmt  . 

/• 

True 

when  a  do  statement  is  found  */ 

i  n  t 

notstmtend; 

/• 

False  when  the  end  of  a  statement  is  found 

•/ 

i  n  t 

n  umwa its; 

/• 

The 

number  of  iterations  for  the  final  wait 

logic 

•/ 

i  n  t 

c  on  t  ; 

/• 

Used 

to  find  the  begining  of  the  next  statement 

•/ 

i  n  t 

n  x  t  c  h  r  ; 

/• 

The 

index  into  the  current  line  for  the  next 

char. 

*/ 

i  n  t 

j  ; 

n  umwa its  =  0  . 

nocoend  =  TRUE; 

if  ((fgets  (line. 

00 

(S> 

nput ) )  ==  NULL) 

i  /• 

read  new 

fprintf(stderr 
return  (0); 
l 

,  "EOF 

found.  Missing 

coend\n") ; 

> 

else  j 

n  x  t  c  h  r  =  0  ; 

/• 

next  character 

is  index  0 

*/ 

1 c  ou  n  t  ++  ; 

/• 

increment  1 ine 

count 

•/ 

i 


while  (nocoend)  j  /•  do  while  no  coend  statement  is  found  •/ 

dostmt  =  FALSE; 
notstmtend  =  TRUE; 


/• 

Loop 

u  n  t 

i  1  a  new  s  t  a  t  erne  n  t  or 

a  coend 

is  found 

/• 

This 

loop  is  for  skipping  over 

blank 

i  i  ne  s 

and 

/• 

f  i  n  d  i 

'  n9 

coend  statements.  The 

c  o  e  n  d 

must 

be  on 

/• 

line 

t  y 

itself  and  not  within 

c  statement 

So 

/• 

look 

f  o  r 

coend  before  entering 

end  c  f 

stmt 

logic 

coni  =  TRUE. 

w  h 

ile  ( c  o  n  t  ) 

) 

while 

( ( ' 

sspace  (  i  i ne[nitchr  ]  )  ) 

&&  (  1  i 

n  e  [  n  x 

tchr) 

n  x  t  c  h  r  +  +  ,  /•  find  first  nonspace  char 


*/ 

•/ 

./ 

♦/ 

•/ 


An  '  )  ) 


fprintf  (trout.  "First  cha 
switch  (  I  i  ne[  mtchr  ]  )  j 


on  new  stmt  JEc  \  n  "  , 


I  inefnxtchr]). 


/•  if  o  coend  is  found  then  insert  code  for  wait  loop  •/ 


/»  and  leave  the  forkstmts  routine.  If  a  cobegin  is  •/ 
/»  found  print  on  error  message  Placing  a  cobegin  »/ 
/»  block  between  statements  of  o  cobegin  block  will  •/ 
/•  accoup I i sh  nothing.  •/ 
case  ’  c  ’  : 

if  (  !  strncmp  ("coend".  Ill  ine[n*tchr],  5))  j 


fprintf  (trout,  "coend  found  ot  line  ?5d\n".  Icount); 
nocoend  =  FALSE; 

prwoits  (numwaits,  col);  /»  insert  wait  logic  •/ 

notstmtend  =  FALSE;  /•  no  more  stmts  to  find  •/ 

if  (!  pop  ())  /  *  popstackseporater  •/ 

return  ( 0 )  ; 

i 

else  if  ( !  strncmp  (“cobegin".  &line[nxtchr],  7))  j 
fprintf  (stderr.  "Improper  placement  of  cobegin") ; 
return  (0); 

i 

cont  =  FALSE;  /•  exit  loop  •/ 

break; 

/•  If  a  new  line  is  found,  read  in  the  next  line  •/ 

/«  if  EOF  is  found,  then  print  error  message  •/ 

case  ' \n ' : 

fprintf  (output,  "55s"  ,  line); 

if  ((fgets  (line,  80,  input))  =  =  NULL)  J 

fprintf  (stderr,  "EOF  found,  Missing  coend\n"); 

return  ( 0 )  ; 

I 

else  j 

nxtchr  =  0;  /•  reset  index  and  increment  line  count 

I c  o  u  n  t  ++ ; 

fprintf  (trout,  "line  read  \n”,  Icount); 

i 

break, 
d  e  f  a  u  I  t  : 

cont  =  FALSE;  /•  next  statement  is  found  •/ 
break; 


(nocoend)  )  /*  if  no  coend  stmt  hos  been  found, 

if  (I  push  (';',  Icount))  /»  then  fork  off  the  next  stmt  and 

return  (0);  /♦  increment  numwaits 

n  umwa  i  t  s  +  +  , 

fprintf  (trout,  "Numwaits  is  now  55d\n",  numwaits); 
prforks  (col); 

This  next  loop  finds  the  end  of  each  statement  by  using  o  stock. 
A  switch  statement  is  used  to  evoluate  eoch  chorocter.  The  top 
of  the  stack  and  the  next  character  reod  determines  the  oction 
to  be  taken  The  following  logic  is  applied: 

The  stack  top  is  a  Whenever  o  symbol  is  found  which 

matches  the  top  of  the  stack,  pop  the  stock  If  the  stock  is 
empty,  then  the  end  of  the  statement  has  been  found  If  a 
is  found  and  the  top  of  the  stack  is  o  then  o  block 

statement  is  found  and  the  end  of  the  statement  will  be  o 
Therefore,  pop  the  ’  off  the  stock  and  push  the  ‘  i  '  However, 
if  the  block  is  a  dc  statment,  then  do  not  pop  the  ’  ;  ’  If  a 
newline  char  is  found,  then  read  the  next  line  )f  o  '  "  is 
found,  push  it  on  the  stock  and  ignore  all  else  until  another 
'  "  ’  is  found  If  a  j'  is  found  ignore  all  characters  except  a 
'  "  '  until  a  is  found  If  a  '  <  '  is  found  and  the  top  of  the 

stot  >  is  o  then  ignore  a  I  ■■  other  characters  except  '  "  ’ 


finir 
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/•  until  a  ')’  is  found.  if  another  cobegin  is  found,  then  coll  •  / 

/•  forkstmts  recursively  to  separate  and  fork  the  stotments.  */ 


while  (notstmtend)  J 

switch  (  I  i ne [ nx t c h r  ]  )  j 


/•  statement  end  has  not  been  found  »/ 


/•  If  a  d  is  found,  check  for  a  do  loop.  The  do  loop  »  / 


/  *  is  a  special  cose.  A  do  loop  will  be  enclosed  by  •  / 

/  *  the  j  and  j  symbols,  but  will  end  in  a  ;  symbol.  •  / 

/  *  Do  not  pop  the  ;  symbol  off  the  stack  *  / 

case  ’  d  '  : 

fprintf  (trout,  "Case  d  at  J5d\n",  Icount); 
if  (stk.sym[stk.top]  ==  ’ 

if  ((!  strncmp  ("do  ",  4line[nxtchr],  3))  || 

(!  strncmp  ("doj",  41  ir.  e(nxtchr],  3)))  j 

fprintf  (trout,  “do  while  found  on  line  %d\n",  Icount) 

dostmt  =  TRUF  ; 

\ 


n  x  t  c  h  r  ++ ; 
break, 


/•  get  next  character  */ 


/•  If  a  c  is  found,  then  check  for  a  new  cobegin  block.  »/ 
/  •  If  a  new  cobegin  block  is  found,  recursively  coll  •  / 
/•  forkstmts  routine  to  process  the  block.  •  / 


f  (!  strncmp  ("cobegin",  t I  i ne[nx tchr]  ,  7))  ) 

fprintf  (trout,  "cobegin  found  at  line  %d\n" ,  Icount); 


if  (!  push  ('4’,  Icount))  /•  push  on  stack  separater  •  / 
return  (0); 


f  (forkstmts  (nxtchr))  }  /  •  call  forkstmts  recursively  •  / 

fprintf  (trout,  “•••Returned  from  c oe nd • • • \ n  "  ) ; 
fprintf  (trout,  "Top:  %d\n",  stk.top); 
fprintf  (trout,  "Symbol:  %c  \n",  stk.sym[stk.top]); 


/•  Returned  OK  so  read  next  line  •/ 
if  ((fgets  (line,  80,  input))  ==  NULL)  j 

fprintf  (trout,  "Missing  Zc  from  line  5Sd  on  stock\n" 
stk.sym[stk.top],  stk.  lnum[stk.top]); 
fprintf  (stderr,  "EOF  found.  Missing  coend\r,"); 
return  (0); 


else  j 

nxtchr  =  0,  /• 

I  count  ++  , 
fprintf  (trout, 


reset  index  and  increment  line  count  •/ 


line  7od  read  \n",  Icount); 


else  )  /•  Bad  return  from  forkstmts  routine  •/ 

fprintf  (stderr,  “Bod  cobegin  block  \n"); 
return  ( 0 ) . 


else  if  ('  strncmp  ("coend",  4  I  i ne[ nxtchr]  ,  5))  j 

fprintf  (stderr,  "coend  found  with.n  statement\n"); 
fprintf  (stderr,  "Missing  End  of  S 1  a t em e n t \ n " )  , 
return  ( 0 ) , 

! 

else  r.  xtchr++,  /•  get  next  character  •/ 
break  , 


/•  If  o  new  line  is  found,  read  in  the  next  line  •  / 
case  '  \ n  ' 

fprintf  (trout,  "Case  newline  at  %  d \ n ’  ,  Icount); 
fprintf  (output,  "7tS  '  line  , 

if  ((fgets  (line,  80,  '  nput  i  ]  ==  NULL  )  T  ♦  EOF7  •/ 


I 
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fprintf  (trout,  "Missing  7, c  from  line  %d\n", 

stk.sym[stk.top],  stk.  I num[ st  k .  top]  )  ; 
fprintf  (stderr,  "EOF  found,  Missing  coend\n"); 


return  (0); 


else  j 

nxtchr  =  0;  /  •  Next  line  read,  index  is  0,  •/ 
I  c  o  un  t  ++ ;  /  *  increment  line  count  •  / 

fprintf  (trout,  "line  55  d  read  \n",  Icount); 


break; 


/»  If  (  is  found  and  top  of  stock  is  either  ;  or  ),  »/ 
/•  push  the  symbol  )  on  the  stack  •/ 

case  ’ ( ' ; 

fprintf  (trout,  "Case  (  at  line  55  d  \  n  "  ,  Icount); 
if  ((stk . sy«[st  k .top]  =  =  ’)')  ||  (stk. sym [stk. top]  == 

if  (!  push  (')’,  Icount)) 
return  (0); 

nxtchr++;  /*  get  next  character  •  / 

break; 


/  *  If  o  j  is  found  and  the  top  of  the  stack  is  either  a 


/•  or  a  (,  then  push  the  }  on  the  stack.  Pop  the  stack  if  •/ 


/•  the  top  is  a  ;  and  dostmt  is  FALSE, 
case  ’ ) ' : 

fprintf  (trout.  "Case  j  at  line  %d\n",  Icount) 

if  ( ( s t k . sy m [ s t k . t op ]  ==  ’;')  kk  (dostmt))  J 
if  (I  push  (  ’  j  ’  ,  Icount)) 
return  ( 0 )  ; 

I 

else  if  ( s t k . s ym [ s t k . t op J  ==';')  j 
if  ( !  pop  (  )  ) 
return  (0); 

if  (I  push  Icount)) 

return  (0); 

I 

else  if  (stk. sy*[s  t  k . top]  ==  '{’) 

if  (!  push  ('{',  Icount)) 
return  (0); 

nxtchr++;  /*  get  next  character  •/ 

break  ; 


/•  If  )  is  found  ond  top  of  stock  is  ),  then  pop  it  */ 
/•off  the  stock.  •/ 

case  ’ ) ' 

fprintf  (trout,  "Case  )  at  line  55  d  \  n  "  ,  Icount); 
if  (stk  sym[stk.top]  ==  '  )  ’  ) 

if  (I  pop  (  )  ) 
return  ( 0  )  ; 

nxtchr++,  /•  get  next  character  •/ 

break; 


/•  If  a  |  is  found  and  top  of  stack  is  (.  then  pop  the 

/•  stock  and  check  if  stock  is  empty  If  the  stock  is 

/•  empty,  then  insert  exit  code  and  statement  end  has 
/•  been  found 
case  '  ( 

fprintf  (trout,  "Case  (  o'  line  55  d  \  n  '  ,  Icount); 
if  tstk.sym[stktOf]  ==  '(')  ) 

if  (  1  pop  (  )  I 

return  (  0  )  , 

if  (empty  ())  )  /•  empty  stock''  •  / 

nxtchr  =  printexit  (f  +  rxtctn  ,  col).  / •  ins 

if  (nxtch-  ==  -1)  / •  bad  return  •/ 

reluin  ( 0  ;  . 
notstmtend  =  FALSE 


n  s  e  r  t  exit  • . 


I 


E 
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else  nxtchr++;  /*  get  next  chorocter  */ 


else  nxtchr+4; 
break ; 


/•  get  next  character  •/ 


/•  If  a  ;  is  found  and  the  top  of  the  stack  is  a  ; 

/»  then  pop  stock  and  check  if  stack  is  empty.  If 

/»  stack  is  empty,  insert  exit  code  and  stolen,  e  n  t 

/•  end  is  found. 


fprintf  (trout.  "Case  ;  at  line  %d\n",  Icount); 
if  (stk.sym[stk.top]  ==  ‘  ;  '  )  j 

if  ( !  pop  ( ) ) 
return  (0); 

if  (empty  ())  j  /♦  empty  stack?  */ 

nxtchr  =  printexit  (++nxtchr,  col);  /*  insert  exit 
if  (nxtchr  ==  -1)  /»  bad  return  */ 

return  (0); 
notstmtend  =  FALSE; 

i 

else  nxtchr++;  /•  get  next  character  •/ 


else  nxtchr++;  /*  get  next  chorocter  •/ 
break; 


/•  If  a  "  is  found  and  the  top  of  the  stack  is  olso  a  ",  *  / 
/•  then  pop  the  stack,  other* i se  push  the  "  on  the  stock.  •/ 
case  '  \ " ’  : 

fprintf  (trout,  “Case  \"  at  line  %d\n",  Icount); 
if  (  s t k . sym [ s t k .  t o p ]  ==  ' )  } 

if  (  !  pop  ()) 
return  (0); 


else 

if  (!  push  ( ’ \ " ’ .  Icount)) 
return  ( 0 )  ; 

nxtchr++;  /*  get  next  chorocter 

beak; 


d  e  f  a  u  I  t  : 

n  x  t  c  h  r  ++ ; 
break; 


/•  get  next  character  */ 


return  (1); 


W5 


/•  The  routine  find_block  is  called  by  the  mo i n  routine  for  every  •/ 
/•  file  entered  by  the  user.  The  main  purpose  of  find_block  is  to  •/ 
/«  search  the  input  file  for  a  cobegin  block  and  to  call  the  •/ 
/•  routine  forkstmts  to  process  the  block.  find_block  opens  three  »/ 
/«  files;  the  input  source  file,  the  output  source  file,  and  a  •/ 
/•  a  trace  file.  The  output  file  contoins  the  new  C  source  code.  «/ 
/*  The  trace  file  contains  a  trace  of  the  stock  operations  •/ 
/«  performed.  Given  an  input  file  name  of  XXX. c,  find_block  will  •/ 
/•  create  the  output  file  with  the  name  XXXp.c  and  the  trace  file  •/ 
/»  with  the  name  XXXt.d.  The  trace  file  will  be  retoined  only  if  *  / 
/•  an  error  occurrs  while  processing  the  input  file.  •/ 


find_block  (filenum,  argv,  orgc) 

int  filenum;  /»  The  number  of  the  file  in  argv  •/ 

char  «  a  r  g v [  ]  ; 
int  a  rgc  ; 

1 

FILE  *fopen()  ; 

static  char  trace[15]  =  J "  "};  /•  The  name  of  the  trace  file  •/ 

static  char  temp[l5]  =  j"  "j;  /•  The  name  of  the  output  file  */ 

int  i,  noerror; 

noerror  =  TRUE;  /»  noerror  indicates  an  error  in  the  input  file  *  / 
stk.top  =  0  ; 

/»  open  input  file  •/ 

if  ((input  =  fopen  ( a r g v [ f i I e n urn ] ,  "r+w"))  ==  NULL)  ) 

fprintf  (stderr,  "Could  not  open  file:  SJs\n",  org»[f i lenum]) ; 
e  x  i  t  (  2  )  ; 

i 

e  I  se 

fprintf  (stderr,  "Opened  input  file;  %s\n",  argv[filenum]); 

strcpy  (trace,  argv[f  i  lenum]) ;  /»  copy  name  of  input  file  •/ 

strcpy  (temp,  a r g v [ f  i  I  e n urn ] )  ;  /*  to  both  trace  and  output  •/ 

i  =  0  ; 

while  (temp[ i ]  !  =  ’•’)  i++l 

trace[  i  ]  =  '  t  '  ; 

t  em  p [ i  ]  =  'p'; 

trace[++i]  =  /•  These  instructions  complete  the  •/ 

tempf  i]  /»  names  of  the  trace  and  output  •/ 

trace[++i]='d';  / *  files.  •/ 

t  em  p [  i  ]  =  '  c  ‘  ; 

t  race [++  i  ]  =  ' \0  '  ; 

tempi  i ]  =  ’ \0  1  ; 

/»  open  output  file  •/ 

if  ((output  =  fopen  (temp,  "w"))  *==  NULL)  J 

fprintf  (stderr,  "Could  not  open  file  %s\n",  temp); 

exit  ( 2  )  ; 

f 

e  I  se 

fprintf  (stderr,  "Opened  output  file  JSs\n",  temp); 

/•  open  trace  file  •/ 

if  ((trout  =  fopen  (trace,  "w"))  ==  NULL)  ) 

fprintf  (stderr.  "Could  not  open  file  %  s \ n "  .  trace); 

exit  ( 2  )  ; 

i 

else  j 

fprintf  (stderr.  "Opened  Trace  File  %  s \ n "  ,  trace), 
fprintf  (trout,  "Trace  of  Cobegir,  -  Coend  Block  \n\n "  )  . 

i 

I  count  =  0  ; 

/ *  This  loop  will  read  the  input  file  and  write  to  the  •/ 


/  *  output  file  until  a  cobegin  block  is  found.  At  that  •/ 

/*  time,  the  routine  forkstmts  is  colled  to  process  the  •/ 

/*  cobegin  block.  If  the  routine  'main'  is  found,  then  •/ 

/•  the  array  ' p i dor  roy '  and  the  variables  pid,  ii,  jj,  •/ 

/•  and  status  are  inserted  into  the  output  file.  These  */ 

/»  ore  used  by  the  fork  and  wait  code.  •/ 

/•  If  on  error  is  found  in  the  file,  return  o  1.  »/ 

while  ((((gets  (line,  80,  input))  !=  NULL)  ift  (noerror))  j 

I  c  o  u  n  t  ++ ; 

i  =  0  ; 

while  (isspoce  (  I  i n  e [  i ] ) )  i++; 

if  (!  strncmp  ("main'',  ft  I  i  n  e  [  i  ]  ,  4))  j  /»  found  'main'? 

fprintf  (output,  ■'  i  n  t  pidarroy[25];\n"); 
fprintf  (output,  “int  status,  pid,  i  i  ; \ n " ) ; 
fprintf  (output,  "static  int  jj  =  j 1 j ; \ n “ ) ; 

i 

if  (strncmp  ("cobegin",  ft  I  i  n  e  [  i  ]  ,  7))  /•  found  ’  cobeg i n 

fprintf  (output,  "55s",  line); 

else  ) 

fprintf  (trout,  "cobegin  found  at  line  55d\n”,  Icount); 
push  (‘ft’,  Icount); 

if  (!  forkstmts  (i))  j  /  *  process  cobegin  block  •/ 

noerror  =  FALSE; 

fprintf  (stderr,  "Bad  cobegin  block\n"); 

! 


if  (noerror)  J 

fprintf  (trout,  "EOF:  %s\n",  a r g v [ f i  I e n um )  )  ; 
fprintf  (stderr,  "Number  of  lines  in  file  55s:  %d\n", 
a r g v [ f i  I e num  ]  ,  Icount); 


/•  close  files  »/ 
if  (((close  (input))  ==  EOF) 

fprintf  (stderr,  "Could  not  close  file:  %s\n' 
if  (((close  (output))  ==  EOF) 

fprintf  (stderr,  "Could  not  close  file:  3s\n' 
if  ((fclose  (trout))  ==  EOF) 

fprintf  (stderr,  "Could  not  close  file:  ?5s\n' 


argv[filenum]) 
temp) ; 
trace); 


/•  check  for  errors 
if  (noerror)  ) 
unlink  (  t : ace)  ; 
return  (0); 

\ 

else 

return  (  1  )  ; 
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/• 

/• 

/* 

/* 

/* 

/• 

/• 

/* 

/• 


The  main  routine  simply  checks  to  see  how  many  tiles  were  entered 
by  the  user  and  to  fork  a  separate  child  to  process  each  file. 

If  the  user  doesn’t  enter  a  file,  an  error  message  is  printed. 

The  user  may  enter  only  6  files.  This  is  because  a  user  can  only 
have  20  files  opened  and  each  file  entered  requires  three  opened 
files  (input,  output,  and  trace).  If  only  one  file  is  entered, 
the  parent  will  process  the  file  and  no  children  will  be  created. 
If  a  child  has  an  error,  then  it  returns  the  file  number  of  the 
file  it  was  processing  and  the  parent  will  print  an  error  message 


*/ 

•/ 

*/ 

•/ 

*/ 

•/ 

•/ 

•/ 

*/ 


main  (argc,  or  g v ) 


i  n  t 

argc; 

char  ♦ a  r  g  v  [  ]  ; 

i  n  t 

i,  err,  pid,  fi 

1  e n  urn  , 

noc  h 

i  Ids; 

u  n  i 

on  wait  status; 

i  f 

(argc  <  2)  ) 

/* 

D  i  d 

the  user  enter  a  f 

ilename?  »/ 

) 

fprintf  (stderr, 
exit  ( 1 ) ; 

"Must 

Give 

A  File  Name!\n"); 

J 

»  f 

(argc  >  7)  ) 

/• 

Did  the  user  enter  too 

many  files? 

fprintf  (stderr, 
exit  ( 1 ) ; 

"User 

May 

Only  Input  6  Files 

!  \n  "  )  ; 

nochi  Ids  =  0 ; 
f  i  I  e  n  urn  =  1  ; 


/*  number  of  children  is  0 
/•  file  numbers  start  with  1 


>/ 

>/ 


setbuf  (stderr,  NULL);  /•  don't  buffer  output  to  standard  error  device  »/ 


if  (argc  ==  2)  }  /•  only  one  file,  don’t  fork  any  children.  */ 

err  =  find_block  (filenum,  argv,  argc); 
i  f  (  e  r  r  ) 

fprintf  (stderr,  "Error  on  File  %s\n",  orgvffilenum]); 


/  •  fork  a  child  for  eoch  file  *  / 


else  j 

while  (argc  !=  1)  ) 

if  (fork  ()  ==  0)  j 

err  =  find_block  (filenum,  orgv,  argc); 
if  (err) 

exit  (filenum); 
else 

exit  ( 0 ) ; 

I 

argc--; 

filenum++;  /•  increment  file  number  and  number  of  children  «/ 

no  c  h i  Id  s++ ; 


for  (i  =  0,  i  <  nochi  Ids;  i +  + )  )  /»  wait  for  the  children  to  finish  •/ 

pid  =  wait  (tstatus)  ; 

if  (status  w_status  !=  0)  J  /•  the  chila  returned  an  error  •/ 

if  ('  status. w_termsig) 

fprintf  (stderr,  "Error  on  File  % s\ n " ,  orgv[status.w_retcode]); 
else  ) 

fprintf  (stderr.  "Terminotec  by  System  Error.  %u\n", 
status. w_termsig)  . 
if  (  status  w_coredump) 

fprintf  (stderr,  "Core  Dump  Token\n”); 
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Parallel  Pascal 


y! 

i 


Any  Pascal  program  can  be  linked  to  the  Parallel  Programming  Library  by  including  the 
-mp  option  on  the  Pascal  compiler  command,  pascal.  A  user  must  declare  the  routines 
in  the  Parallel  Programming  Library  as  C  external  procedures  or  functions  within  their 
Pascal  program  by  using  the  keyword  cexternal.  The  functionality  of  these  routines  is  the 
same  for  Pascal  as  for  C.  Reference  the  “Balance  8000  Guide  to  Parallel  Programming’’ 
for  further  information  on  using  these  routines  in  Pascal.  However,  the  routines  fork, 
exit,  and  wait  are  not  part  of  the  Parallel  Programming  Library  and  can  not  be  directly 
referenced  from  a  Pascal  program.  A  user  must  first  write  a  function  in  C  which  performs 
the  actual  fork,  exit,  or  wait  and  then  link  this  function  to  their  Pascal  program.  This 
is  very  simple  to  accomplish.  Again,  the  C  functions  are  linked  to  the  Pascal  program 
by  declaring  them  as  cexternal  functions  or  procedures.  Any  C  function  which  returns 
an  integer  must  be  declared  in  Pascal  as  returning  a  long  integer  (longint).  Place  the  C 
functions  in  a  separate  file  and  compile  them  using  the  Pascal  compiler.  This  file  must  have 
the  “.c”  file  extension.  The  pascal  command  is  smart  enough  to  call  in  the  C  compiler 
for  this  file.  Also,  when  the  C  compiler  compiles  the  C  functions,  it  places  an  underscore 
before  the  name.  The  functions  must  be  declared  and  referenced  in  the  Pascal  program 
using  this  underscore.  Pascal  also  passes  parameters  in  reverse  order  to  C.  Thus,  if  you  call 
a  C  function  and  pass  parameters  A,  B,  and  C  in  that  order,  the  C  function  will  receive  the 
parameters  in  the  order  of  C,  B,  and  A.  If  any  C  function  references  a  Pascal  procedure, 
you  must  also  include  the  -e  option  when  compiling  the  files.  When  a  C  function  returns, 
the  calling  function  releases  the  stack.  When  a  Pascal  function  returns,  the  called  function 
releases  the  stack.  The  -e  option  ensures  that  the  calling  C  function  releases  the  stack  not 
the  called  Pascal  function. 


» 


The  following  two  files  demonstrate  the  ability  to  fork  procedures  in  Pascal,  terminate 
the  processes  (exit),  and  synchronize  (wait).  The  Pascal  procedure  “add”  adds  a  value 
to  a  counter  in  an  array  of  counters  and  prints  its  value.  This  program  adds  different 
amounts  to  five  different  counters,  concurrently.  Before  each  call  to  the  procedure  “add”, 
the  procedure  “_fk”  is  called.  This  procedure  is  a  cexternal  function  which  performs  a 
fork  and  returns  the  process  ID.  The  parent  process  will  receive  the  new  PID  of  the  child 
process  and  the  child  process  will  receive  a  zero.  The  child  process  performs  the  “add” 
operation  and  then  calls  the  procedure  “.ext”.  This  procedure  is  a  cexternal  function 
which  performs  an  exit.  At  the  end  of  the  program,  the  parent  process  calls  the  function 
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“_wt”  for  every  child  process.  This  function  is  also  an  cexternal  function  which  performs 
a  wait  and  returns  the  PID  of  the  exiting  process.  The  first  file  is  the  Pascal  program. 
The  second  file  is  the  C  functions  which  call  fork,  exit,  and  wait.  The  array  of  counters 
is  placed  in  shared  memory  since  all  global  variables  in  Pascal  are  shared.  This  example 
implies  that  every  routine  a  C  program  can  reference  can  also  be  used  by  a  Pascal  program. 
However,  the  user  is  cautioned  when  performing  I/O.  If  the  main  program  is  written  in 
Pascal,  use  Pascal  for  the  I/O.  This  example  also  implies  that  the  cobegin-coend  construct 
can  be  easily  extended  to  Pascal  programs. 
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/•* . / 

/•  FILE  1  */ 

/ . / 

/•  This  program  increments  an  array  of  five  counters.  The  counters  */ 


/•  are  global  (shared  memory).  The  function  ‘add"  odds  a  value  to  »/ 
/•  a  counter.  Each  counter  is  incremented  concurrently  by  calling  •/ 
/*  the  functions  _ f k ,  _wt,  and  the  procedure  _ext.  These  are  »/ 
/*  external  C  functions  which  perform  the  routines  fork,  exit,  and  •/ 
/»  wa it.  »/ 


program  counters  (input,  output); 

const 

size  =  5 ; 

v  a  r 

counter  or  ray[l  .  .size]  of  integer; 
i  integer; 
result  longint; 

procedure  add  (num,  value  integer); 
begin 

counterfnum]  :=  counterfnum]  +  value; 

•r i Icln  ('counter  num,  '  is  ' ,  counterfnum],  '■’) 

end, 

procedure  _ext;  cexternal; 
function  _  f  k  longint.  cexternal, 
function  _wt  longint;  cexternal; 

begin 

for  i  :=  1  to  size  do 
counter [ i ]  : =  0  ; 

result  =  _  f  k  ; 
if  result  =  0  then 
beg  i  n 

add  ( 1 ,  10); 

_  e  x  t 
end; 

result  ;=  _  f  k  ; 
if  result  =  0  then 
begin 

odd  2  .  15); 

_  e  x  t 
end; 

result  '=  _  f  k  ; 
if  result  =  0  then 
begin 

add  ( 3  ,  20); 

_  e  x  t 
end. 

result  :=  _  f  k  , 
if  result  =  0  then 
begin 

add  ( 4  ,  25); 

_  e  x  t 
end. 

result  :=  _  f  k  , 
if  result  =  0  then 
begin 

add  ( 5  .  30 )  . 

_  e  x  t 
end; 

I  c  i  :  - 

begin 


1  to  size  do 
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NAME 

intro  -  introduction  to  Poroilel  Programming  Library 
DESCRIPTION 

These  routines  constitute  the  Parallel  Programming  Library, 
which  supports  microtasking  and  multitasking  in  C,  Pascal, 
and  FORTRAN  programs.  (For  information  on  microtasking  and 
multitasking  programming  models,  refer  to  the  Balance  Snide 
io  Parallel  Exaaxatnmifla • )  The  Parallel  Programming  Library 
is  not  supported  under  System  V  (flii  universe). 

The  routines  decribed  here  include  the  current  Parallel  Pro¬ 
gramming  library,  /usi/lid/ Litpae • a .  and  the  previous  ver¬ 
sion,  /usi/lib/libpp • a  The  older  version  is  retained  for 
compatibility  with  earlier  DYNIX  releases.  The  routines 
from  the  current  library  are  linked  into  a  program  by 
including  the  ~lpps  option  in  the  cc  or  Id  command  line,  or 
by  including  the  -Ipps  or  -mp  option  in  the  fortran  or  pas¬ 
cal  command  line.  The  routines  from  the  old  library  are 
linked  by  including  the  —  I  p  p  option.  You  must  not  link  both 
libraries  with  the  same  program. 

For  an  overview  of  how  the  current  Parallel  Programming 
Library  routines  are  used,  and  for  sample  programs  ond 
related  information,  refer  to  the  Balance  Quids  la  Eaxallsl 

Exaaxammina 

LIST  OF  FUNCTIONS 

The  following  routines  support  microtasking: 

Hans  £cesaxs  an  Eaas  Deccxxpiicn 

9  ro_fork  m_fork.3p  execute  o  subprogram  in  poral lei 

m_get_myid  m_ge t _my i d . 3p  return  process  identification 

m_g e t _ n urn p r o c s  m_ge t _nump r oc s , 3p  get  number  of  child  processes 

m_kill_procs  m_kil!_procs.3p  kill  child  processes 

m_lock  m_lock.3p  i ni t iol i ;e  ond  lock  a  lock 

m..  multi  m_sing!e.3p  end  single-process  section 

m_next  m_next.3p  increment  global  counter 

m_park_procs  m_park_procs.3p  suspend  child  process  execution 

m_rele_procs  m_park_procs.3p  resume  child  process  execution 

m_set_procs  m_set_procs.3p  set  number  of  child  processes 

m_single  m_sing!e.3p  start  single-process  section 

m_sync  m_sync.3p  check  in  ot  barrier 

m_unlock  m_lock.3p  unlock  a  loci 

The  following  routines  support  multitasking 

dame  Apfigaxs  an  Eaas  BsscxiciiaD 

9  cpus_online  cpus_online.3p  return  number  of  CPUs  on-line 

s_  c I oc  k  s.lock  3p  lock  olocx,  return  if  unsuccessfu 

I 

s_ i n  i  t_bor  r  i  er  s_woit_barrier  3p  initialize  a  barrier 
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s_ i n i t_ I ock  s  _  I  o  c  k  .  3  p  initialize  a  lock 

s_lock  s_lock.3p  lock  a  lock 

S_LOCK  s_lock.3p  lock  a  lock  (C  macro) 

s_unlock  s_lock.3p  unlock  a  lock 

S_UNLOCK  s_lock.3p  unlock  a  lock  (C  mocro 

s_wait_barrier  s_*a i  t_ba  r  r i e  r  . 3p  wait  at  a  barrier 


The  following  routines  support  memory  allocation  for  paral¬ 
lel  programming.  The  fexJs  and  .sfeiJs  routines  ore  available 
without  loading  the  Parol  lei  Programming  library  (see 
fexii  (  2  )  )  ,  but  the  versions  in  the  Parallel  Programming 
library  are  necessary  for  compatibility  with  the  rest  of  the 
I i brary . 
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Name 

brk 
s  b  r  k 
shbrk 
s  h  f  r  e  e 
s  hma I  I oc 
s  h  s  b  r  k 


DYNIX  Programmer's  Manual 


Appsaxs  an  Eflfls 
b  r  k  .  3p 
b  r  k . 3p 
s  h  b  r  k  .  3  p 
s hma I  I  oc . 3 p 
shmal loc.3p 
s  h  b  r  k  .  3  p 


I  NT RO ( 3P ) 


Dfisaxipiian 

chonge  privote  data  segment  size 
change  private  data  segment  size 
chonge  shared  dato  segment  size 
deallocate  shared  data  memory 
allocate  shared  data  memory 
change  shared  dato  segment  size 


The  following  routines  constitute  the  previous  version  of 
the  Parallel  Programming  library.  /aax/lib/iibPP  a,  and  are 
retained  for  compatibility  with  earlier  releases: 


9  p_cpus_online 

em 

p_finit_barrier 
p_ i n  i  t 

c  Lock  Memo  r  y 

p_ i n i  t  _ba  r  r  i e  r 
p_ i n i  t  _ I oc  k 
p_ I oc  k 
p_shmal  loc 
p_  u  n I oc  k 
p_wo i  t  _bo  r  r i e  r 


Appeaxa  2D  Ease 

p.cpus.on I i ne . 3p 

p_wai t_barr ier . 3p 
p  _  i  n  i  t  .  3  p 


p  _  w  a i  t_barrier.3p 

p_ I oc  k . 3p 

p_ I oc  k . 3p 

p_  s  hma I loc.3p 

p_ I oc  k . 3p 

p_wai t_barr ier ,3p 


Dssaxipiian 

get  number  of  processors  in  syst 

initialize  a  barrier  (FORTRAN) 
initialize  shored  memory  ond  Atom i 

initialize  a  barrier 
initialize  a  lock 
lock  o  lock 

a  I  locate  shored  memory 
unlock  a  lock 
wait  ot  o  barrier 


The  following  routines  are  retained  in  the  old  Parallel  Pro¬ 
gramming  Library  for  compatibility  with  earlier  releases, 
but  are  not  described  elsewhere  in  these  man  pages: 

P_«.&li  is  equivalent  to  fizii(3). 

is  equivalent  to  the  standard  FORTRAN  routine 
ihali 

p_iiflii  has  no  effect. 
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